United States Patent [i9] 

Call 



llllllllllll 

US006154738A 
[11] Patent Number: 6,154,738 
[45] Date of Patent: *Nov. 28, 2000 



[54] METHODS AND APPARATUS FOR 

DISSEMINATING PRODUCT INFORMATION 
VIA THE INTERNET USING UNIVERSAL 
PRODUCT CODES 

[76] lovenlor: Charles Gainor Call, 53 Saint Stephen 
St., Boston, Mass. 02115 

[ * ] Notice: This patent is subject to a terminal dis- 
claimer. 



[21] Appl. No.: 09/316,597 
[22] FUed: May 21, 1999 

Related U.S. Application Data 

[63] Continuatiod-in-part of application No. 09/049,426, Mar. 
27, 1998, Pat No. 5,913,210. 

[51] Int. Cl.^ G06F 15/173 

[52] U.S. CI 707/4; 707/513; ^707/3; 

707/10; 705/20; 705/23; 705/26; 709/201; 

709/213; 709/217; 709/249 

[58] Field of Search 707/10, 4, 3, 513, 

707/524; 705/20, 23, 26; 395/200.31; 709/201, 

213, 217, 249 

[56] References Cited 

U.S. PATENT DOCUMENTS 

5,794,221 8/1998 Egcndorf 705/40 

5,804,803 9/1998 Cragun et al 235/375 



5,918,214 6/1999 Perkowski 705/27 

5,950,173 9/1999 Perkowski 705/26 

6,045,04« 4/2000 Wilz, Sr. el al 235/472.01 

Primary Examiner— icsm R. Homere 

[57] ABSTRACT 

Methods and apparatus for disseminating over the Internet 
product information produced and maintained by product 
manufacturers using existing universal product codes (bar 
codes) as access keys. A cross-referencing resource, which 
may take the form of an independent HTTP server, an LDAP 
directory server, or the existing Internet Domain Name 
Service (DNS), receives Internet request messages contain- 
ing all or part of a universal product code and returns the 
Internet address at which information about the identified 
product, or the manufacturer of that product, may be 
obtained. By using preferred Web data storage formats 
"which conform to XML, XLS, XLink, Xpointer and RDF 
specifications, product information may be seamlessly inte- 
grated with information from other sources. A "web regis- 
ter" module can be employed to provide an Internet interface 
between a shared sales Internet server and an otherwise 
conventional inventory control system, and operates in 
conjunction with the cross-referencing server to provide 
detailed product information to Internet shoppers who may 
purchase goods from existing stores via the Internet. 

14 Claims, 8 Drawing Sheets 
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METHODS AND APPARATUS FOR widely used in retail stores for barcode scanning at checkout 

DISSEMINATING PRODUCT INFORMATION counters, and the Internet addresses where information can 

VIA THE INTERNET USING UNIVERSAL be obtained about the products designated by those codes. 

PRODUCT CODES In a principle aspect, the present invention takes the form 

5 of methods and apparatus for delivering information about 

CROSS-REFERENCE TO RELAI^ED products and manufacturers via the Internet using all or part 

APPLICATIONS of the universal product codes which designate these prod- 

•mis is a continuation in part of U.S. application Ser. No. "<f '^^ manufacturers as lotemet access keys. The product 

09/049,426 filed on Mar. 27, 1998 and entiUed "Methods ,„ ^formation is stored in Internet servers, preferably in XML 

and Apparatus for Disseminating Pioduct Infonnation via fomat, by the manufacturers who both produce the products 

the Internet", now U.S. Pat. No. 5.913.210. P"^"*=^ information. 

Internet shoppers and others who desire product informa- 

REFERENCE TO MICROFICHE APPENDIX tion fetch web pages via the Inteniet fitom on-line merchants 

^ . and other sources. These web pages may contain one or 

A microfiche appendix consistmg of 28 frames on one 15 ^^^^ ij^^s to product information, and each such Unk 

microfiche accompanies this specification and contams Perl ^^j^j^^ ^ reference which designates a particular product 

language CGI scnpis (computer source language hstings) ^y its conesponding universal product code. When the web 

which illustrate working illustrative embodiments of ^^^^ ^ ^ ^^^^^ , ^ ^ 

selected componenis of the mvention. A poruon of the ^ ^ containing at least a portion of the universal 

disclosure of this patent document contains material which 20 d„ct code is sent via the Internet to a cross-iefcrencing 

IS subject to copyright protection. The copynght owner has ^^^^ preferably maintained by the Internet Domain 

no objection to the facsimile reproduction by anyone of the ^^^^ ^^^^ ^ I^,^^, ^^j^^ „f ^^^^ 

patent document or the patent disclosure as It appeals m the ,icu,a, manufacturer's server which then makes the 

Patent and Trademark Office patent file or records, but ^^^^^ information available. 

otherwise reserves all copynght rights whatsoever. 25 ^ .• .• j. ^-i j 

" " The present mvention may be used to particular advantage 

FIELD OF THE INVENTION provide product information to web customers who visit 

web sites operated on behalf of retail stores which use 

This invention relates to methods and apparatus for trans- universal product codes both for bar code checkout and to 

ferring requests for specific information to preferred sources identify specific products in a computerized inventory con- 

of that information on the Internet. ^ irol system. The retailer's inventory control systems need 

...^ „^ not store detailed product information since, by means of the 

BACKGROUND /^DSUMMARY OF THE invention, the univeisal product codes of items being offered 

IIUIN ^ access product information directly 

Manufacturers must provide information about their prod- from the manufacturer's servers, 
ucts to resellers, consumers, and others. Resellers need In one embodiment of the invention, the cross-referencing 
product information to select, promote and support the function may be performed by a server which receives a 
products they distribute. Consumers need information about hypertext transport protocol (HTTP) request message con- 
available products to make informed buying choices. taining a universal product code, performs a lookup opera- 
Advertisers, product analysts, manufacturer's ^ tion using a stored database of cross-references, and returns 
representatives, i^ippers, and others also need information an HITP response message which includes a location header 
about the goods with which they deal. field containing a destination URL specifying said particular 

Under current practices, product information typically Internet address. The requesting web browser then aulomati- 

originates with manufacturers and is primarily distributed in cally redirects the request message to the destination URL. 

conventional print media advertising and product packaging. ^5 The company code portion only of the universal product 

This information is often incomplete, difficult to update, and code may be stored in the cross-referencing database to refer 

available only to a limited distribution. While the advent of a product information inquiry to the server operated by the 

the World Wide Web has permitted manufacturers to make manufacturer, with the remainder of the product code being 

detailed, up-to-date product information available via the sent to the manufacturer's server to identify the particular 

Internet, the information describing a specific product is 5Q product. This reduces the size of the cross-referencing 

often difficult to locate, particularly when the URL (uniform database, and further simplifies the process of registering 

resource locator) of the manufacturer's website is not manufacturers and maintaining the database, 

known. When the cross-referencing server takes the form of an 

It is a general object of the present invention to transfer a independently operated server, the standard Light-weight 

request for information specified by an identifier, such as a 55 Directory Access Protocol can be employed to advantage to 

product code, to a preferred source of that information, such provide cross-references between all or part of each univer- 

as an Internet information resource devoted to the product sal product code and the Internet address where information 

specified by the product code which is created and main- about that product may be obtained. Access to product 

tained by the product's manufacturer. information can be even more simpUfied and expedited by 

The preferred embodiment of the present invention 60 using the existing Internet Domain Name service to perform 

employs an Internet resource, called a "product code cross-referencing, a capability which can be added to the 

translator,** for storing cross-references between universal existing Internet infrastructure by simply reserving a preas- 

pioduct codes identifying specific products and Internet signed name space for product code to address conversion, 

addresses specifying the locations at which information By storing product information expressed in extensible 

about these products may be obtained. The cross-references 65 Markup Language (XML), and by using stylesheet infor- 

specify the universal product codes assigned to the partici- mation provided by the web site which is incorporating 

pating manufacturers, such as the U.RC. and EAN codes product information into their web presentations, the data 
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supplied by the manufacturer can be rendered using font sal product code system. In accordance with the present 

sizes, typefaces, background colors and formatting selected invention, the Internet is employed to provide low cost, 

by the web page producer. Other characteristics of XML, worldwide, bi-directional communication which enables 

including the ability to encourage or enforce conformity product information to be requested by and sent to any 

with content and formatting standards through the use of 5 Person or firm using one or more universal product codes as 

Document Type Definitions (DTD*s)and the Resource Defi- information access keys. The univeisal product code system 

nition Framework (RDF) and Syntax Specification, facilitate ^ i° ^^^Pf^^'^ ^ to umquely identify each of the thou- 

the integration of data from retailers and other web page ^^f^ of different suppheis and milhons of different items 

produce^, .vith the product information provided by manu- ^^^SS ^fi^S'^^^^^^ 

tacturers. i invention, a product code translator which may be accessed 

When the manufacturers of some products identified on jjjg internet provides information enabling the translation 

web pages have not made product descriptions available, it universal product codes into the associated Internet 

is desirable to suppress the creation of visible link anchors addresses at which information about the products specified 

which encourage users to attempt to activate links which ^^^^ product codes may be obtained. 

wiU not work as intended. Such link suppression can be 15 The present invention enables the retrieval of information 

accomplished by determining the status of each desired link ^^^^ ^^^^^^ ^^^^ ^^ose products. typicaUy 

before the web page containing the product list is displayed. manufacmrer, by those who need that information, such 

"Image-cued linte perfonn this function by empb^^^^ ^^^^^1^^^ consumers. In accordance with the 

hnk anchors, visible web page components such as miage ^^^^^^^^ any person or firm having access to the Internet 

files which are retrieved via the cross-referencmg server at 20 ^^^^ ^^.^^^^^^ ^^^^^^^ ^^^^ ^ p^^^^^ 

the time the web page is displayed. ^^^^^ information about that product from the participating 

These and other objects, features and advantages of the manufacturer which supplies that product. The system 

present invention will be made more apparent through a employs a product code translator, which may be imple- 

consideration of the following detailed description of a mented by a plurality of servers but which is illustrated by 

preferred embodiment of the invention. In the course of this ^5 ^^^j^ resource seen at 101 in FIG. 1. ITie product code 

description, frequent reference will be made to the attached translator is accessed via the Internet to perform a translation 

drawings. of specified universal product codes into the corresponding 

BRIEF DESCRIPTION OF THE DRAWINGS Internet addresses from which information about the desig- 

nated products can be obtained. 

HG. 1 is a schematic block diagram illustrating various ^^^^^^^ translator 101 stores cross-references 

instrumentalities which make use of the invention intercon- between product codes and Internet addresses. The product 

nected via the Intemet; codes and the Internet addresses are provided by or on behalf 

FIG. 2 is a diagram illustrating the interrelationship of tiie of participating manufacturers and suppliers, such as the 
principle data structures used to implement a product code manufacturer illustrated at 103 in FIG. 1. ITiese cross- 
translator of the type contemplated by the invention; references may then be retrieved from the cross-reference 

FIGS. 3 and 4 are a flow diagram depicting the operation resource 101 by resellers, prospective buyers, as illustrated 

of a CGI program which implements the product code by the distributor 105, the retailer 107 and the customer 109 

translator, responding to request HTTP messages containing seen in FIG. 1. Internet Service Providers, as illustrated by 

universal product codes and redirecting those request mes- the ISP 111 in FIG. 1, may also utilize the data provided by 

sages to the URLs where information about designated the product code translator 101 to provide a variety of 

products may be found; services and functions. 

FIG. 5 is a data flow diagram illustrating the manner in Before further describing how these entities function 

which a web browser interacts with a server which acts as a within the system, it will be useful to clarify some of the 

product code translator by redirecting links on a merchant's 45 terms which will be used in this specification: 

web page to product information made available by the The term "universal product codes" (lower case) is used 

manufacturer; to indicate standardized industry or inter-industry codes 

FIG. 6 is a data flow diagram iUuslrating a further used to designate items, packages and services made, used, 

embodiment of the invention in which a web browser leased or sold in commerce. The term thus includes the 

interacts with a domain name server which serves as a 50 Universal Product Codes ("U.P.C.s") used by suppliers in 

product code translator, redirecting links on a merchant's the United States and Canada and managed by the Uniforai 

web page to XML data provided by a shared sales server Code Council, Inc., 8163 Old Yankee Road, Dayton, Ohio 

used by several merchants, the XML data from the manu- 45458; the BAN codes used by suppliers outside the U.S. 

facturer being displayed in accordance with an XSL and Canada under the general direction of EAN 

stylesheet specification unique to each merchant, and die 55 International, rue Royale 145, 1000 Bruxelles— Belgium; 

online merchant functions being implemented by the shared and any other multi-industry or single industry standard 

sales server which is connected to the conventional inven- product designation system. 

tory control system operated by each of the merchants; and The term ''manufacturer" will be used to refer to 

FIGS. 7 and 8 are a block diagrams illustrating the manufacmrers, suppliers, vendors, licensors and others to 

principle components of a typical retailer's inventory control 60 whom sets of universal product codes have been assigned, or 

system and the interface between that system and a shared their agents. TypicaUy, this assignment takes the form of the 

sales server which maintains a parallel but more limited designation of a particular value for a portion of the uni- 

inventory database used during on-line sales transactions. versal product code which is reserved for exclusive use by 

rM-T- r-rx T-.i^ei-niiynriKT * particular manufacturer. For example, the entity to which 

DETAILED DESCRIPTION ^ specific six-digit "company-identifier" portion of a 

The present invention takes advantage of two existing and 12-digit numeric U.P.C. code has been assigned is a "manu- 

highly successful technologies: the Intemet and the univer- facturer" as that term is used in this specification. 
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The term "product" is used to refer to a kind of item which Uniform Record Locator constituting the "base address" at 

is uniquely identified by a single universal product code, as which information can be retrieved about products desig- 

opposed to a specific individual item of that kind. For nated by those universal product codes, company informa- 

example, a specific U.RC. code is assigned by the tion fields which include the company's name, mailing 

manufacturer, Hershey Foods Corp., to 'Reese's Creamy 5 address and email address fields so that the manufacturer 

Peanut Butter" as packaged in 510 gram containers (a submitting the registration can be identified. and^cog|^d; 

"product") whereas a different U.RC. code is assigned to the » date field which specifies the date upon which the 

same peanut butter packaged in containers of a different size registration was first made. ^ 

(a different "product"). registration handler 203 may obtam the submitted 

^ ». nu J* f».u 11 in data needed to create the registration template record in a 

The term Internet address will be used to refer to the all, - . e u rsTxir u <• 

. c , , r f . vanetyofways, such as acceptmg a HTML web page form 

or a significant part of, a reference to a resource on the , ^ , j j • *u i * . u • * 

i» fcu <^ *i»u<: f -1 completed and submitted via the Internet by a registrant, 

Internet. Such a reference may take the form of a numerical *^ , . . . - - 7L 

,r,,. -iT-^: r» f. processing an incommg email message contaimng the nec- 

IP address or an alphanumenc Uniform Resource Locator .5' .. u 

/«»T^.T»^ L J r vc j i_- cssary infonnation. Or rccciving thc nccdcd mformatiOH by 

("URL ) which may identify a file on a specified machine, / i -i 

^.^.^ c J. .i_ ic telephone or regular mail, 

a database query, a specific command output, or some Other J; - . . „ ^ . 

accessible Internet resource. Thus, the term "Internet The registration handler process preferably incorporates a 

address" includes such things as a specific 32-bit address of mechanism or procedure for insuring that the registrant has 

a specific computer connected to the Internet, written in t"*?"!;"^ jQ^create and alter the mformation being 

decimal as "123.040.212.002"; a domain name such as supplied. A variety of methods tor enhanciHgthe secunty of 

>teiitsoft.com" which can be resolved into a numerical 20 registration process may be employed, mcludmg the 

IP-address using a domain name server; the URL of a file '^*"f°'^^ °i " V'f'^'"^ tune a range of umversal 

accessible via the Internet, such as "ftp://www.sample.oora/ P,™''"^' ^o'^^^ 6,^*' registered, with the requirement that 

director/fllename.xxx"; a URL identifying a query process- "'^^^■"^ Pf be thereafter provided by anyone who 

ing script with passed parameters, such as "http:// ^^^^ '° ^^'^ "\e inforiiiation onginaUy provided with 

xxx.yyyy.com/cgi/search%01234567890123"; or an email 25 respect to any product code within that previously registered 

address such as "847563@manufacturer.com". ""Sc Tbt iggjsmjero^ductjnaji^^^ 

re gistrant to provide an email con tact address to which an 

The Product Code Translator eimil.messagLof, predeteFm^ c ongui is &sii^dflg|rgte-' 

initial.registrat ion form is com pleted, to wKich the registrant" 

The product code translator seen at 101 in FIG. 1 per- 3^ must respond within a predetermined time to verify the 

forms two primary functions illustrated in FIG. 2: (1) its registration. Any attempt thereafter to change the contact 

registration handler 203 accepts cross-references submitted email address results in a message being sent to the origi- 

by manufacturers which relate their assigned universal prod- nally registered email contact address advising that an 

uct codes to associated Internet addresses where information attempt is being made to alter the registration. Finally, email 

relating to their products may be obtained, and (2) its query 35 confirmation may be requested from the email address 

handler 204 accepts queries via the Internet 205, each query registered with InterNIC for the URL to which universal 

including all or part of one or more universal product codes, product codes are to be linked This step confirms that the 

and returns the Internet addresses which can be used to person attempting a registration in fact has authority to link 

obtain information about the products identified by those to that host computer and provides an additional safeguard 

codes. The product code translator 101 may also advanta- against unauthorized submissions. 

geously perform other functions, examples of which are Instead of maintaining a user name and password 

described below. database, the registration handler can use a database of 

As seen in FIG. 1, the product code translator 101 may be certificates, such as Certificate Server available from 

advantageously implemented by a server computer which Netscape, to create, sign, and manage certificates for all 

stores information in a relational database consisting of the 45 participating manufacturers, configuring other servers to 

tables depicted in FIG. 2. If desired, the product code accept only authorized user certificates. A scalable database 

translator 101 may be implemented with a plurality of may be used to store the status of each certificate, and the 

"mirrored" servers at different locations, or clustered servers Issuance and revocation of certificates can be centrally 

at the same location containing the same cross-referencing administered from the product code translator or a separate 

data to share the processing burden and provide redundant 50 registration authority. Similar password, certificate or digital 

fault-tolerant reliability. In addition, different servers or sets signature protection schemes may be used to provide access 

of mirrored or clustered servers may be used to process to certain data or to data in certain forms only to authorized 

different assigned subsets of the gamut of universal product requesters. 

codes. Whether one or many servers is used, each may be The information contained in the incoming registration 
preferably implemented using conventional server hardware 55 template 207 is used to create records (rows) in three 
and conventional server operating system software, such as separate tables in the relational database: a company table 
Microsoft NT Server, Netscape Application Server, SCO 211, a URL table 213 and a cross-reference table 215. As 
UnixWare, Sun Enterprise Server, and the like. seen in FIG. 2, the company table 211 includes a numerical 
The registration handler process 203, which may be company number field CoNo which is also present in the 
implemented on a server which stores cross-references, or 60 cross-reference table 215 so that each cross-reference table 
on a separate server operated by a central registration row can be related to a particular company description 
authority, receives each registration submission via the Inter- record in the company table which has the same CoNo 
net 205 to create an incoming registration data illustrated by value. The key field CoNo establishes a one-to-many rela- 
the data template record 207. The registration template tionship between the company table 211 and the cross- 
record 207 includes several fields: an Company-ID field 65 reference table 215 since a participating company identified 
which holds the company-identifier portion of a universal by a unique CoNo value may register more than one set of 
product code in BAN format; a URL field which holds the universal product codes, potentially associated with different 
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IP-addresses, requiring more dian one row in the cross- are ordinarily available and easer to renaember, and because 

reference table 215. it may be desirable to later change numerical IF addresses 

The Company-ID field in the registration template record while retaining the same URL, the use of URL's for rcgis- 

is used to complete two fields, FromCode and ThruCode, in tratioo is preferred. 

a row in cross-reference table 215. These fields specify a 5 Note also that, because URL/IP address assignments may 

range of one or more consecutive universal product codes. g^ded, altered or deleted on a daily basis by the URL 

Both of these two fields preferably stores a 64-bil integer assignment authority, updates to the DNS tables should also 

which specifies a 14 decimal digit universal product code reflected by automatic updates to the cross-reference 

drawn from the global pool of 14-digit numbers which ^^^^^ ip.Address fields. In this way, a change in URL/IP 

mcludes the U.RC, EAN-13 and SCC-14 codes. In this way, 10 address assignments propagated in the DNS system require 

all three coding systems can be accommodated by the oo additional action on behalf of the manufacturers to insure 

cross-reference table 215; for example, a 12-digit U.RC. continuing abiUty of the product code translator to 

number 7 12345 12345 9 is the same as the 13 digit EAN ^^^^^ appropriate new IP addresses in response to 

number 07 12345 12345 9 and the same as the 14 digit universal product code queries. If, as discussed later, the 

SCC-14 number 0 07 12345 12345 9. If the U.RC. six digit 15 1^^^^^^^ domain name system itself is used as the product 

company identifier 7 12345 is specified in the registration jp ^^dress translation mechanism, updating two 

template Company-ID field, the FromCode field of the ^^^^^ ^^^j^ ^e unnecessary, 

cross-reference table record would be loaded with the num- ^ . . , , ^. • 4 »• 

ber 71234500000 to specify the lowest valued universal ^""^f"^ badcgroumi the registration and 

J , J f J * »u J- in query/response functions performed by the product code 

product code cross-referenced to the corresponding IP m ? 1 * i_ ■ ^ r « u • 

■ .u thaj c*u * ui '>ic ^ J translator may by summarized as follows: each participatmg 

address m the IPAdr field of the table 215, and the ThruCode c ^ u u if u 

c u ij u 1 J J -^u -7i-»ivicnnnnrt . c *u mauufacmrer, or someone actmg on its behalf, submits a 

field would be loaded with 71234599999 to specify the . , ^. \ . , . 

, J* J f j* registration which generates an incommg registration tem- 

highest valued universal product code cross-referenced to . , r . - . . ® x • . • 

*u . in AA T-u f .u 1 1 /u- u 1 plate 207 contammg information about the registermg 

that IP address. The use of the low-value/high-value range ^ ^ . • 1 j* ^ . c c *i_ • 1 

c ^. c ,j . . c si. c * manufacturer, includmg an ideatincation of the umversal 

specification fields m each row of the cross-reference table , , j u- u j • * j, * r u- u • r 

lie * f ' 1 J.J product codes which designate products for which informa- 

215 permits difterent ranges of universal product codes f. • , . . 1 wT * *u ♦u .u unr u- u 

, • ,u o 1 * u • * J •*u lion IS to be made available, together with the URL which 

having the same Company-ID value to be associated with £.1.1. . u- u n 1 * j . 

A'fe . 1 4 . AA • *u jnAA a lA f*u specifies the Internet resource which will make that product 

different Internet addresses m the IPAdr field of the cross- • r i_i 

c .ui^iff.u ui- -1 c ^ information available, 

reference table 215, thus enablmg a single manufacturer _ ... * ^ • 

having a single assigned Company-ID value to store infor- 30 ^"PP^^ ^ ^^^^^^ ^^^^^ and 

mation about different products designated by different sets converted mto a numencal IP address m the IPAdr field of 

of its universal product codes on different Internet servers, ^ ^ Table 213 usmg an available domain n^e server 

or to cross-reference non-continuous sets of universal prod- ^17. This 32 bit IP address is stored in the IPAdr field of the 

uct codes to the same or different servere. Note further that cross-reference record (row) in table 215, along with a 

a manufacnirer need not cross-reference all of its available 35 specificaUon of the universal product codes of the products 

assigned universal product codes, but may omit unused described by mformatioo which is available at this IP 

codes or codes designating products for which no informa- address, the range of codes being specified by the values 

tion is to be made available. stored in the FromCode and ThruCode fields in the ne w 

The IP-address field in each row of the cross-reference re cord in cross-reference table 215 .. >J 

table 215 holds a 32-bit IP address used to route Internet data ^qP^^^^ incommg query is received hv the query handler H 

packets to a destination computer using the TCP/IP protocol. 204^a table lookup function is performed by searchiog-the 

The 32-bit IP address value in the cross-reference table 215 cross-reterence lapie Zi5 for a row record or records which 

is obtained from the IP address field of the URL table 213 specify a set of umversal product codes which include the 

, and that 32-bit address value is prefetched by querying a or codes specified by the query If matching row(s) are 

conventional domain name server (DNS) seen at 217 45 ^^^^^^ IP-address(es) found in the matching row(s) are 

assigned to the cross-reference resource 101. The DNS 217 returned to the query submitter; otherwise, a special code 

translates the alphanumeric URL in the URL field of the (such as a zero valued IP Address) is returned to indicate that 

URL table 213 into the current 32-bit IP address used by information for the product code(s) of interest has not been 

Internet routers to guide data packets to the proper destina- registered. 

tion computer. The alphanumeric URL in the URL field of 50 Th^ Internet resource which acts as the product code 

the URL table 213 is supplied via the registration template translator can additionally perform some or all of the fol- 

207 when Internet location of the manufacturer's product lowing additional functions: 

description data is supplied during the registration process. It can respond to a request for information about a 

The separate URL table 213 has a one-to-many relation- particular participating manufacturer and return to the 

ship to the cross-reference table 215 and uses the 32-bit IP 55 requester the information in the company table 211 as well 

address value as the relational key. This arrangement allows as the specification of all of the registered universal product 

a single URL base address to be shared by a plurality of codes assigned to that participating manufacturer and the IP 

different manufacturers. Thus, for example, a single Internet address (or URL) of the location where further information 

service provider (ISP) may act as a shared Internet resource on the products designated by the registered universal prod- 

for storing data about a products originating from many 60 uct codes may be obtained. 

different manufacturers. It is accordingly unnecessary for ^ The product code translator can re spond to a query 

each manufacturer to operate its own server or have its own co ntaining a designation o f one or more univere al product 

assigned URL. Instead, a manufacturer may place its prod- codes b y identit ying the e mail"a gdress ofjhc_manufacturcr. 

uct descriptions on any server having an assigned Internet The product code translator, or any other computer which 

address. Note that it is fiirther unnecessary for the manu- 65 obtains cross-references between universal product codes 

facmrer to have, or supply, an assigned URL rather than a and email addresses from the product code translator, may 

numerical IP address; however, since corresponding URL's act as an SMTP forwarding, agent; for example, forwarding 
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e mail whic|^ contains a designation of unive rsal prndiict 
c ode frqm a sender to an email address rir-jj^pntrd hy the 
manufacturer of the product deggnated^hv t hat code . 
Alternatively- resell^a attd mherir"may obt ain emaij^ 
a ddresses fro m the prod uct code translator which can be 
included m ^*m5ilgr" -hyp"ertext Unks m product listi^ s^ 
allowing a weopage viewer to display and co mplete a blank 
cmair fequest tdfTntormai ion w hich is routeg~directly to lE e 
manufact urer's cEsignateci email'address . The email address 
retufned'in response to a request may be a standard email 
address such as "upcmfo@domainname" where ''domain- 
name" is the domain name portion of the URL supplied by 
the manufacmrer, in which case the specific universal prod- 
uct code would, by convention, be supplied as all or part of 
t he "subje ct" of the email me ssage sent to that address , 
en abUng tne manufacturer to laeniity the sp ecific product 
which is the subjec t ot the inquiry. 

he product code translator can turther provide all or part 
of the information from company table 211 to provide 
information about the manufacturer(s) to whom registered 
universal product code or codes are assigned. Note that, in 
general, the information which is required or recommended 
for inclusion with other company information may be lim- 
ited to that data necessary or desirable to enable the code 
translator to perform its functions. Other information about 
the company may simply be placed in an allocated 
namespace on the manufacturer's server. 

ThQ cross-referencing utiUty can provide the entire con-" 
tents of its URL table to a requesting computer, such as a 
search engine which can then perform conventional "web 
crawler" indexing of the websites specified by the listed 
U RLs and/or IP address es, thereby generating complete or 
partial indexes to all or less than all of the products whose 
product description locations have been registered with the 
product code translator. 

The cross-reference table 215 can be scanned by the 
product code translator in response to a request for certain 
universal product codes only; for example, books are 
assigned EAN numbers which always begin with the prefix 
number 978 before the company-id value (publisher 40 
designation) portion of the International Standard Book 
Number (ISBN) which makes up the remainder of the EAN 
number for each book, allowing all IP addresses for infor- 
mation about books to be provided by the cross-referencing 
server to create a database or index to book information. In 
the same way, the cross-reference table could be scanned for 
product codes assigned to a particular manufacturers (e.g. 
book publishers) to provide a more focused index. 
The product code translator, as noted earlier, may facifi-*^ 
^ tate the registration process by providing a website frorn jso 
which HITVIL registration form pages -may be fetched, 
d^filayed a nd c ompleted using a conventional web-brow ser 
p rogram . In addiiion, the product code translator may advan- 
tageously make query forms available to permit information 
request queries to be made direcdy, as well presenting 
informational web pages which p rovide instructions and 
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gu idelines for registration procedures, recommendations far 
t he^ stg as^ int ofmation on registered informat ion 
r esources, and instructions and downloadable softw are 
wh ich may be used to simplify and facilit ate, searche s and 
funct ions performed at other resources on tfielntern et which 
utilizct he service s- Diovided by the product c ode translator. 
When, as discussed later, the Internet domain name service 
is employed to perform product code or company code 
translation to an Internet address, the a uthorized DNS ^rcg; 
istr atiop authorities can provide informational and registr a- 
tion services to registrants. 



55 



65 



llie present invention provides significant advantages and 
opportunities to manufacturers. Information which manu- 
factures now distribute in other ways can be made imme- 
diately available to those who need or desire that informa- 
tion. Examples include text and graphics which describe and 
promote the sale of each product to potential buyers; product 
labeling information, some of which may be required to be 
made available to potential buyers such as product weights 
and volumes, ingredients, nutritional facts, dosage and use 
instructions, some or all of which is now included on 
product packaging and which can be reproduced as mixed 
text and graphics HTML page for viewing by distributors, 
retailers, advertisers, catalog publishers, potential customers 
and purchasers; logos, photographs of products, and other 
graphics files in a variety of resolutions for use by both 
electronic and print rendering to promote product sales, 
usage and support. Instructional and service information 
including self-help diagnostics and recommended solutions, 
product part lists and ordering information, product return 
procedures, current pricing information, identification of 
dealers and distributors, warranty and guarantee 
explanations, and support telephone numbers may be pro- 
vided. 

The scope and content of the information each manufac- 
turer makes available is completely under the control of that 
manufacmrer. In order to make this information accessible in 
a standard way, it is desirable that the manufacturer conform 
to standard resource naming conventions so that interested 
parties which obtain the manufacturer's registered IP 
address from the product code translator can find the desired 
information at this address. This naming convention may 
take numerous forms, and the following are merely exem- 
plary: 

A root directory named "upcinfo" may be created on each 
registered computer, and a subdirectory having a name 
which is the universal product code (expressed as a zero- 
filled, right-justified fourteen digit number) is created to 
hold the information concerning the product designated by 
that universal product code. At the minimum, each such 
directory includes a product home page named "info.html" 
which typically provides whatever general product informa- 
tion the manufacturer wishes to place before all interested 
parties. This product home page may hnk to additional 
information related to the product on other pages when 
appropriate. 

By way of example, a product HTML home page for a 
book would be created by the book's publisher and could 
include a complete bibliographic citation identifying the 
title, author, book type (hardcover, paperback, etc.), recom- 
mended retail price, ISBN number, number of pages, pub- 
lication year, etc. In addition, each book's home page might 
include an imbedded thumbnail image (JPEG or GIF file) of 
the book jacket, and links could be added enabling the 
viewer to see additional information concerning that book 
when available, such as an interview with the book's author, 
quotes from favorable reviews, book group discussion 
guides, a table of contents or introductory chapter, etc. 

Thus, information imiquely formatted to best advantage 
by the manufacturer could be made available by accessing a 
single URL, having the same form for all products, formed 
by combining the IP-address obtained from the standard by 
concatenating a prefix and sufiSx. The suffix has the form: 

-/iipcinfon234567890l234/info.html" 
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where the numerical part of the suffix is the universal 
product code directory name, and where the suffix is 
appended to the at the end of the prefix of the form: 

"http;//23.m40,198" 

consisting of the protocol identifier "http://" and by the 
32-bit IP address from the product code translator written in 
its standard four decimal number format (four three digit 
numbers separated by periods, each of which is a value in the 
range 0-255 representing the binary value of one of the four 
8-bit bytes making up the 32-bit IP address). 

If a manufacturer stores product information in a 
database, the product directories and the HTML and other 
data files which are to be made available can be rewritten 
automatically under program control as the information in 
the manufacturer's database changes. Alternatively, a 
request for a particular "file," such as the web page desig- 
nated "/upcinfo/product-code/info.html," may be inter- 
cepted at the manufacturer's server and handled as a data- 
base query to which the server responds by dynamically 
writing an HTML response page using information in the 
manufacturer's product database. Available database pro- 
gram development tools, such as Microsoft's Access 97 and 
Borland's Delphi 3.0, include database manipulation tools 
which allow programs to be readily written which automate 
the process of generating product description pages from an 
existing database. 

Hie present invention may be employed to allow the same 
information found on a product's packaging to be made 
available to prospective online buyers. For food products, 
for example, in addition to the product name, logo and 
promotional materials, such existing packaging information 
typically includes an ingredient list, nutrition facts, serving 
suggestions and directions, recommended recipes, and prod- 
uct guarantee information. Over the counter 
pharmaceuticals, cosmetics and health care products often 
include further information, such as specific directions on 
dosage and use, warnings and instmclions in the event of 
misuse, storage and product lifetime information, and active 
ingredient specifications. Frequently, this valuable informa- 
tion is printed on a product container or container insert 
which is discarded shortly after purchase. By making this 
information readily available to purchasers and end-users 
over the Internet, the manufacturer can help insure that such 
valuable product information, some of which may be legally 
required on the product's packaging, is available to the 
consumer at the time of an online sale and after the product 
has been purchased. 

While information of the kind traditionally placed on 
product packaging akeady exists and can be converted by 
the manufacturer into a format suitable for publication on 
the World Wide Web, and thus made widely available at little 
cost, the invention allows information in other forms to be 
provided at low incremental cost. For example, multimedia 
presentations may be presented to promote, describe and 
support a product and its uses. User manuals and service 
documentation can be provided in Adobe Acrobat portable 
document format or the like for viewing and printing by 
resellers, service personnel and consumers. 

It is frequently desirable to transfer to another computer 
data created by the manufacturer which provides limited 
product description information for each product offered to 
enable more efficient indexing, cataloging, inventory 
control, and other applications. By way of example, in the 
bookselling industry, publishers, distributors, retailers, and 
libraries often require a database of bibliographic informa- 



tion which consists, for each book, of the book title, author 
name(s), publisher's name, publication date, type of book 
(hardcover, papeiback, etc.), page count, recommended 
retail price(s), and ISBN number (which takes the form of a 

5 subpart of the EAN universal product code). To the extent 
the content and format of data records which describe 
particular classes of products in particular industries and 
trade groups have been previously adopted and placed in 
widespread use, those structured data records may advanta- 

10 geously be made available utilizing the present invention. 
This is preferably achieved in two ways: a data record (file) 
containing such field-structiued information about each 
product which is designated by a universal product code is 
placed by the manufacturer in the directory it creates for that 

15 product. This structured data record is given a filename 
indicative of the format used to store the strucmred data. For 
example, each directory bearing a name corresponding to the 
EAN number for a book would preferably contain a file 
named "biblio.dat" which contains a single stmctured record 

20 containing bibliographic data describing that book. 

In addition, the manufacturer would place a combined 
file, also called "biblio.dat" in its root "\upcinfo" directory 
which contains all of the records for all of the products 
individually described in the subdirectories which have that 

25 stmcmre in a single file. For most manufacturers, these 
stmcmred data files, both individual record files in the 
subdirectories and the combined file in the root directory, 
may be automatically created and updated on a periodic or 
dynamic basis from the content of the manufacturer's exist- 
so ing database. The use of a single combined file at each server 
permits multi-manufacturer databases to be created by first 
retrieving the IP-addresses of all or part of the cross- 
reference table 215, and then retrieving and merging the 
combined data files from the "/upcinfo" directories from 

35 each identified server. Alternatively, when information about 
all of a given manufacturer's products of a given type is not 
desired, the needed individual structured data files can be 
retrieved from the individual product directories. 
As described later in more detail, the information which 

40 the manufacturer makes available can advantageously be 
stored using the extensible Markup Language (XML), 
which is also well suited for providing metadata which 
defines and describes the meaning of the various kinds of 
information that can be provided about individual products, 

45 groups of products, and the manufacturers and distributors 
from which those products are obtained, 

/t^ This ability to obtain accurate and up-to-date product 
information from the manufacttu^er can substantially reduce 
the cost to resellers, catalog producers, and database vendors 

50 which is traditionally incurred in capturing this data by 
conventional means. For example, a retailer creating a 
computerized inventory control systenJ for the first time with 
previously purchased merchandise may use a conventional 
hand-held barcode scanner to capture the universal product 

55 codes from all goods in inventory, and th en retrieve com - 
ple te and accurate product description records tor each 
pro Huct via the Internet using the present invenfio iT 

The ability to obtain, update, and verify product descrip- 
tion information by accessing manufacturer data can be 

60 readily included as callable functions built into inventory 
control and EDI software used by manufacturers, 
distributors, and retailers. Instimtional "consumers," such as 
hospitals, government agencies, and libraries, may use the 
information to build internal databases for internal use. 

65 The structured records noted above are typically, but not 
necessarily, copied into a separate database which is there- 
after manipulated by the requester. Because each copied 
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database record includes a field containing the universal 
product code, the ability to obtain and verify data in the 
remainder of the record from the manufacturer's server is 
retained. Note that it is possible for the user of the local 
database to verify, update and add to the product information 
specified by the universal product code at the time that data 
is referred to or relied upon. In addition, or in the alternative, 
the database can be periodically and automatically verified 
against current data made available by the manufacturer and 
updated to insure the continued completeness and accuracy 
of the entire local database, 
ii!^ The present invention enables a computer connected to*^ 
the Internet to dynamically r etrieve arfaitrari hLla£ge_auanti- 
ii es of data about an individuaTproduct when needed . This 
capability makes it unnecessary, and normally undesirable, 
to copy "content" into a local database which is not needed 
for structured indexing and retrieval purposes. Thus, again 
using books as example products, the local database might 
consist simply of title, author and publisher information to 
form a searchable local database. This database could be 
built by first obtaining all of the IP-addresses for universal 
product codes beginning with "978" (the EAN prefix for 
books) from the product code translator, retrieving the 
combined "biblio.dat" file from the "/upcinfo" directory at 
each IP-address, and extracting the universal product code, 
title, author and publisher data from these records to form 
the desired search able local databa se. This database may 
th en be rapidly searched to produce an ou tput listing of all 
honl fs meeting ^a ^pecified search cntcna, and comptet g 
in formation abo ut each j p>f the identified books can then b e 
obtain ed using tbe universal product codes . 

General product information indexes can be also readily 
be created by means of conventional "web crawler" index- 
ing engines of the type now widely used to index World 
Wide Web sites. These indexing engines may scan either the 
product descriptions created by the manufacturer in the form 
of HTML or multimedia files, or the structured data files 
containing fielded information, or both. By limiting the 
scope of the information indexed to the product information 
data identified by the product code translator, search results 
produced by these product indexing systems are less likely 
to be obscured by references to other, less relevant infor- 
mation which happens to employ the term or terms used in 
a search request. 

The principles of the invention may be applied to par- 
ticular advantage by online resellers. By making detailed, 
accurate and up-to-date information about products which 
are offered readily available to interested prospective 
buyers, both the reseller and the manufacturer can more 
effectively promote the offered product to an interested 
buyer, and the buyer can make a more informed buying 
decision by obtaining more detailed information which 
facilitates product comparisons and matching the product's 
features with the buyer's needs. 
t In this regard, it may be noted that small retailers can-i^s 
^ em ploy shared software and.. aeiyices. gnd share access t o 
prod uct mformation and promotional materials made^ avail- 
abl e byj be manufacturer in accordance w ith the invention, 
at low costs, enabling even the smallest retailer to offer its 
entire inventory of products (and more) to its customers at 
low cost, with each product being fully described and 
promoted by the materials made available by the manufac- 
turer. Similarly, small manufacturers can effectively describe 
and promote their products throughout a widespread distri- 
bution system by simply placing their available promotional 
and descriptive materials on an available shared server and 
registering the assigned universal product codes together 
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with the shared server's address, for distribution by the 
product code translator, all at minimal cost. 

In addition, the present invention may be used to advan- 
tage in combination with Electronic Data Interchange, a 
standard mechanism for ex changing business docucne nts in 
standard format between computers. EDi systems typically 
use value added networks (VANs), such as the networks 
provided by GE, IBM Atlantis and Sterling, or EDI transfers 
can be made via the Internet using services such a those 
provided by EDI Network of Tumersville, N.J. Using EDI, 
manufacturers make available electronic catalog descrip- 
tions of their products being offered for distribution and 
resale. When a buyer selects products of interest to order 
from the vendor's catalog, the retailer's computer accesses 
the vendor's computer to transfer the U.P.C. codes to the 
retailer's computer without rekeying. The retailer may then 
issue an EDI 850 purchase order transaction which is sent to 
the vendor's mailbox. In addition, the EDI system may 
transfer limited additional information to the retailer, such as 
suggested retail price. When the products are shipped, an 
EDI 856 shipping notice is sent to the retailer containing bill 
of lading information (bill of lading number, carrier and 
weight), purchase order information, and carton contents 
using U.P.C. product codes and counts. The vendor also 
sends an EDI 810 invoice to the retailer in EDI format which 
enables the retailer to process the invoice and schedule 
payment either by check or electronic fimds transfer, using 
an EDI 830 remittance advice transaction to give payment 
details for invoices being paid. 

lliese EDI transactions enable retailers to not only auto- 
mate product procurement functions but also to easily main- 
tain an accurate inventory control system in which each 
product is designated by a universal product code. The 
present invention may be used to augment an EDI system by 
providing resellers and consumers with detailed product 
information for any product designated by a universal prod- 
uct code which is made by a participating manufacturer. 

Internet Service Providers, such as the ISP indicated at 
111 in FIG. 1, may provide shared computer services which 
interoperates with a reseller's inventory control system to 
provide customers with the information they desire before 
and after making purchases. 

As seen in FIG. 1, and as previously discussed, a reseller 
(including both the example distributor 105 and the example 
retailer 107) may be assumed to have conventional inven- 
tory control systems, typically using EDI document 
processing, which includes in each case inventory data 
consisting of at least the universal product code for each 
product and, typically, count numbers indicating quantity on 
hand, quantity on order, quantity backordered, etc. This 
limited part of the reseller's database can be transferred from 
the reseller's inventory database (at 105 or 107) to an ISP 
lU which serves many resellers but maintains a table of 
universal product codes for all goods offered by each reseller 
served, together with the on-hand counts for each code. 

The ISP 111 hosts a website for each reseller served in 
conventional fashion, typically using a domain name 
assigned to the reseller. The ISP further makes available 
online merchant software which enables customers to search 
the reseller's website for products of interest, and view lists 
of products resulting from each search. Examples of such 
merchant software include Microsoft Site Server, available 
from Microsoft Corporation, and Merchantec Softcarl mar- 
keted by Mercantec, Inc. of Lisle, 111. Using the present 
invention, product listings presented to customers by these 
online merchant software systems may be enhanc&d with 
links to detailed information about any product of interest 
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made available by participating manufacturers. The search- automatically redirect the original request to the new loca- 

able product database used by the ISP 111 may be built, as tion specified in the location response header. 

described above, using the universal product codes supplied The Perl CGI program processes an incoming HTTP 

by the retailer to access the strucnired data files made message request directed to a URL of the form "http:// 

available by the participating manufacturers (e.g, manufac- 5 www.upcliak.com/cgi-bin/show?isbn=123456789(y* which 

turer 103 in FIG. 1) at the IP-addresses supplied by the is parsed as follows: "www.upclink.com/cgi-bin" is the 

product code translator. name of the directory holding the show.pl Perl program and 



(a The implementation of the invention may be facilitated by 
* supporting software which performs a number of utility 
functions. As noted above, programs may be readily written 
to automate the conversion of information s tored in a 
manufacturer's e xisting pro duct data base into the form of 
static" or dynamically generated H I'MIT p ages which can be 
tran smitted to ful£ll~inlormation requ ests routed_ to-4be 
manufac turer by the cr^ ^-referejpcing.facility. Industry and 
inter-industry groups can promulgate standards and guide- 
lines which will promote consistent formats for product 
descriptions which are accessed in accordance with the 
invention- Inventory control and online merchant software 
can be readily enhanced to take advantage of the availability 
of database records and more robust product descriptions 
which are made available via the Internet. Product informa- 
tion can be made available at terminals and kiosks placed in 
retail stores, showrooms and public places. 



show?isbn=1234567890" calls the show.pl CGI program 
and passes to that program the parameter "1234567890" 
represented by the parameter name "isbn". The ability to 
execute Perl CGI programs is a common feature of most web 
servers, and is described, for example, in "Developing CGI 
Applications with Perl'* by John Deep and Peter Holfelder, 
ISBN 0-471-14158-5 (John Wiley & Sons— 1996). The Perl 
programming language is described in many texts including 
''Peri 5 Complete" by Edward S. Peschko and Michele 
DeWolfe, ISBN 0-07-913698-2 (McGraw Hill 1998). 
Hypertext Markup Language is also widely used and 
described, for example, in "HTML Publishing Bible" by 
20 Alan Simpson, ISBN 0-7645-3009-7 (IDG Books World- 
wide 1996). 

As seen in FIG. 3, the show program is entered at 301 and 
calls a sub routine named get__isbn which processes the 
incoming message. As indicated at 303, the subroutine 
Using HTTP Relocation to Redirect Product get_isbn first loads the input string variable named $isbn 

Information Request Messages with the parameter named "isbn" supplied by the calling 

_ „ , , , J . J . • . message. The subroutine get isbn then calls the subroutine 

The Perl program show.pl, hsted m detail m the micro- . . * ... , « ■ « t » ^ *u ♦ * 

K,, ^ . ™t ^ w . r \ isbn message which returns the string ok if the contents 

fiche appendix, is a CGI (Common Gateway Interface) r c^u r *u ♦ r * icom 

. ' ^ \,, i_ J L . i_ of Sisbn satisfy the requirements for a correct ISBN 

program which executes on a Web server and which operates 30 /i , i c* ^ -a d i m u \ ♦u ♦ ♦u^ ^. • ^ 

1* 41 Ai- TTi^ 1 m.- (International Standard Book Number); that is, the stnng 

as a product code translator as seen at 101 in FIG. 1. This ^ , * • m •* • * ♦u ♦ ♦ ♦ iac a 

... / £1 i_ J J . i_ *u must contain 10 digits as mdicated by the test at 305 and, as 

illustrative program uses a file-based database rather than . , . ^^x'^ a * ■ a -/ * . i * 

»!. t *• 1 5 * 1. J • * J • t-i^ J * u indicated as 307, the first mne digits must translate using a 

the leUtional database depicted m FIG. 2. The datab^ predetermined algorithm (perfoTmed by the subroutine 

consists of a set of files, each of which is designated by a We ^^^^^ ^^^^ j^,^ ^ ^^^^ ^V^., ^^^^ ^^^^^^^ 

name consisting of a company code followed by the suffix 35 , , /iT^ax ii . • »u - ronM u ♦ a 

„ ,„ , . . ^ J, • . r J? last (10^ ) character in the incommg ISBN number stored as 

.xrl and each containmg cross-referencing information for ^^^^ ' $isbn 

all product codes beginning with that company code. ITie ^ 

Perl program show is speciaUy adapted to locate information algorithm for generatmg an ISBN check characters 

on books which are generated by a universal product code ^orks as follows. First, note that an EAN numbers for books 

known as the International Standard Book Number (ISBN), 40 "^^^ ^ converted to the book's ISBN number by removing 

a nine digit decimal number followed by a check character, digits (978) and the last digit from the EAN 

used by the publishing houses, book distributors, retail (^^^ ^^st digit is the EAN check digit, leaving a mne-digit 

bookstores and libraries to uniquely identify books. A van- n^^er. For example, EAN 9780940016330 becomes ISBN 

able number of leading digits of each ISBN designate 094001633 (the first nine digits without the ISBN check 

particular publishers, with the remaining digits being 45 character. To generate the ISBN check character, each ISBN 

assigned by that publisher to designate a particular edition of ^^^^ ^ multiplied by a predetermined associated weighting 

a particular book factor and the resulting products are added together. The 

Ihc Perl program showpl processes an incoming HTTP weighting factors for the first nine digits begin with 10 and 

message containing a parameter which specifies the value of "^^T"!^'^^ \^ "l ^""^ a "^""^ 

a universal product code (in this case, an ISBN number), 50 ^'f^ ^ 9 4 0 0 1 6 3 3 the products sumnied are 

performs a iable lookup operation to retrieve the URL at ^"^V^^^t^tf^.^^f t f 1^^^^^^"^. ^/ 

which information about the product specified by that URL (157/11-14 with 3 remainder) m remainder if 

may be found, and then returns an "error" message to the f^;^^^ subtracted from 11 to get the check digit. (11-3^8). 

requesting browser which contains that URL in the response ft""^^'^!! "1 tc^^kJ '^P'^^°^^^ ^.^"'f 

message's "Location" response field. As specified in Section 55 ^' ^^^^ m our example is accordingly 

10.11 of the Hypertext Transfer Protocol-HTTP/l.O 0-940016-33-8. By generating the check di^^^^ 

specification, RFC 1945 (May 1996), the Location response- "^g ^'^^^ ^^^^ ^^^^^y ^^BN 

header field defines the exact location of the resource that venhed. 

was identified by the Request-URL for type 3xx responses. If the incoming ISBN string passes all of these tests, the 
and the location field must indicate the server's preferred 60 routine isbn_message returns "ok," otherwise, it returns an 
URL for automatic redirection to the resource. Only one appropriate error message and the subroutine send_error_ 
absolute URL is allowed. The response header may also P^ge is called at 309 to write and transmit an HTML error 
include the status code 302 which, under the HTTP protocol, page to the requester, advising that the ISBN number sup- 
indicates that the target data has "moved temporarily" to the pli^d was incorrect. 

URL specified in the location field. In practice, however, it 65 When the request containing an invalid ISBN number is 

has been found that inclusion of a status code value is not being supplied from a source other than the user, such as an 

necessary to enable existing web browser programs to online retailer's web site which employs the ISBN number 
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supplied by its inventory control system, an advisory error If the first line of a multiline control file contains the string 

message can also be sent directly to the reuiler to indicate "list", all of the lines of the control file are read into a hash 

that an error was detected. Although such an advisory should table. Each line contains both an ISBN and the URL where 

be unnecessary, since a similar algorithm for identifying information about the book identified by that ISBN can be 

invalid ISBN numbers should be used by the retailer to 5 found. A hash table lookup is then performed to find the 

validate the data before transmission, it is nonetheless desir- particular line holding the target ISBN, and the desired URL 

able to report such errors to the source as well. The error is obtained from the line found as indicated at 325 in FIG. 

report may sent as an accumulated error log file or as an 4. 

immediately transmitted message sent to a predetermined After the target URL is formed, the subroutine send_ 
error message handling routine provided at the retailer's response returns an HTTP response message to the request- 
server, jug browser which reads: 

If the $isbn variable meets the length and check-digit "Content-type: text/html\n location: Starget \n\n" where 

tests, it is processed by die subroutine make_cocode which ' ^ the URL previously determined is substituted where Starget 

determines, for that ISBN number, how many of the leading appears. This message is interpreted by the web browser / 

digits constitute the "company code" which is assigned to a ^ ^ wh ich receives the message as an indication that the / 

particular publisher. The routine make_cocode performs req uested informat ion (r£q uested from the URL "httpj// | 

this operation by calling the subroutine second_hyphen_ ww wjipclinkxoin/c0-bii i/shQwSisbngl23i^S^^ | 

position which performs tests to determine the number of been relocated to the URL specified by Starget. The request- | 

digits in the company code which can be established from ing web browser then autoSSticailly resendsthe request to / 

the value of $isbn. the location where the needed information is actually j 

nie relationship between any given ISBN and the URL located and do^ so in a way that is transparent to the user 

which identifies the source of information about the book ^^o ^niX normally be unaware that the transmitted request ^ 

designated by the ISBN is selected by the party (typicaUy the ^'^^^ redirected to a different location, 

publisher or its designated agent) which controls the server ^ drawmgs provides an overview of the typical 

which provides that information. Because different pubUsh- „ operation of the CGI Perl script show.pl described above. An 

ers and their web site hosts may use different methods for online shopper mampulales a web browser apphcaUon pro- 

estabUshing URLs for their book information, the Perl script P"? 'f'^^^^^ /^^^ and purchase a particular 

, I . • J . J J- .1. book. In aoing so, the shopper provides the browser 330 

show.pl operates m d^erent ways depending on the com- of an online book retailer which operates the 

pany code $cc which forms the leadmg digits of the incom- ^^^^ ^„ ^, 333 j„ pjo. 5 

ing I6BN. 3Q browsing session, the sales server transmits a web page 334 

The show.pl script handles these differences by fetching a which lists the citations to one or more books, and each of 

file of control information from a file having the name those citations anchors a hyperlink to the cross-reference 

"../link/cocode.xrl" which is constructed from the company server seen at 336. 

code. The portion "../link/" is a predetermined data directory The operator of the sales server which creates the book list 

available to the CGI script show.pl, "cocode" is the numeri- 35 web page needs nothing other than the ISBN number of the 

cal string corresponding to the company code extracted at book to create a link. However, as part of its inventory 

311 from the ISBN by the make_cocode routine, and ".xrl" control system database, the retail web site typically has 

is a standard file suffix. For example, if the incoming ISBN limited additional information, such as the title, author 

is ''8870812345" the routine make_cocode will determine name(s), publisher name, as well as the ISBN. Using this 

that the first five digits are the company code, causing file 40 available infonnation, the book listing webpage can include 

name "../link/88708.xri" to be stored as the variable Scstr. As an informative citation to the book which forms the anchor 

seen at 313 in FIG. 1, the subroutine load_xrl loads the of a hyperlink to additional information. For example, if the 

named control file from local disk space at the cross- . following citation information from the retailer's inventory 

referencing server which executes the Perl script. If the file control system is used to display the following book listing: 

named Scstr is not found, an error report is issued indicating 45 ^ ^^'^ Chicks: A Year in the Violent World of Girl Gangs, 

that no cross-referencing data has been supplied by the By Gini Sikes, Anchor Paperback, ISBN: 0-385- 

company identified by the company code in $cstr as seen at 447432-6. LearnMore 

315 and 317. The hyperlink anchor "Learn More" at the end of the citation 

The contents of the fetched file are then analyzed by ^ formed by the following HTML: 

load xri which fetches the first line and performs a test at 50 

321 (in FIG. 4) to determine if the fetched file is a multiline 

text file with the first line holding the string "list". If not, die hrefo"http://www.upclink.com/cgi-bin/show?isbn«" 

file contains a single line. 0553571656" 

If the file is a single line file, as seen at 323, the contents > 

of the single line are used in combination with the ISBN Learn More 

number to form the URL which specifies where the desired </a> 

book information may be obtained. For example, if the first When the anchor text "Learn More" on the web page 334 

line of the control file named "../link/88708.xrl" contains the is clicked on by the shopper, an HTTP request message 338 

string "hstp://www.upclink.com/ss/.htmr', the subroutine is sent to the href address of the cross-referencing server 

load_xrl inserts the hyphenated form of the ISBN at the 336, triggering the execution of the CGI Peri program 

position indicated by the space to form the URL "hltp:// show.pl which returns the redirection error message 340, 

www.upclink.com/ss/88708-1234-5.html". The first and thereby informing the web-browser 330 that the desired 

second characters of the control file are used to identify information is at a different location. The web browser 330 

variations in the manner in which the ISBN and the control immediately (and transparently to the shopper) reissues the 

file string are combined to form the URL. For example, if request to the address specified in the relocation error 

second character of the control file (an "s" in the example) 65 message. This redirected request, seen at 342, is transmitted 

is an "s", the ISBN is hyphenated before being substituted to the product information server 344 operated by the 

for the space in the string, and the "s" is replaced with a "t". publisher, which returns a web page 346 to the browser 
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containing ttse desired additional infoimation on the book. able from which a cross-reference from an incoming ISBN 

The web page 346 typically includes an image of the book number to a URL can be made. If it the cross-reference can 

jacket, a synopsis of the book, and brief reviews, and may be made, show.pl returns a relocation message containing 

well contain links to additional information provided by the the needed URL whereas button.pl returns the URL of an 

publisher, such as an author interview, a table of contents, or 5 image that indicates that more information is available. If the 

whatever else the publisher may wish to include. In this way, cross-reference cannot be made, show.pl returns an error 

the buyer is provided with up-to-date and detailed book message in the form of an HTML page while button.pl 

information which is equivalent to or superior to the infor- ^^^^^ t^e URL of a null image (either a transparent image 

mation which may be obtamed by picking up the book from ^ ^^ ^^ y ^^^^ j^at the content of the image 

the shelf of a "bncks-and-mortar' bookstore. ^ controlled by the web page producer since the 

Image-Cued Links CGI routine at the cross-referencing server (e.g. button.pl) 

„ . , . may be unique to the caller and may hence return image 

Because additional informatton may not be available via ^RL's specified by the caller. Alternatively, a single CGI 

the Internet &om the pubhsher for all of the books in the ^^^^^ ^^^^ j^^i^j ■ ^rls 

retailer's inventory, it is desirable to provide a mecbamsm ^ parameters to the cross-referencing server, 

which avoids suggestmg that a site visitor should click on ♦ <r * .u u ■ *u ^ 

links that will ultoately prove unworkable. , °" f^' ™ ^^.^ P^^^^ !f "".^ .f PPf '^^'^^ of a 

_ , . . , . . . • , r J . button or other image mviting the site visitor to cuck on a 

The mechanism involves the pnor retrieval of data i- 1 « 1 . ■ c • 1 ui u . 
J . t.- u • I J * J u u • hnk to learn more when more information is available, but 
describing which universal product codes have been regis- ^ *u j- 1 c .i_ u *• * j - 1 u 
tered before web pages containing links using these c(^es to suppress the display of the button, or to display a «no 
are generated. For example, a sales website could transmit a 20 information available button or image when the cross- 
list of the company codes for those universal product codes reference cannot be made. In this way, the site visitor is 
of products to be offered for sale, and obtain in return a aflarmatively mformed when more information is available, 
listing of those company codes which have been registered. and discouraged from looking further when no infonmation 
Alternatively, a list of supported company codes could be is available, while the HTML placed on the book listing has 
periodically broadcast (e.g. by FTP transmission) to sub- 25 a standard form which can be included without prior knowl- 
scribers. The sales website could then use this list to edge of whether needed data is available or not. 
distinguish those products for which additional information n.j.^j/^ n c ♦ it *u 
was being made available by the manufacturer from those ^ode Cross-Referencing Using he 
for which there is no additional information, and include Lightweight Directory Access Protocol 
links on product lists only when they will work. 30 The Internet LDAP protocol may be used to advantage to 

Alternatively, the web page producing site can perform a implement the product code translation process. This 
prior fetch of the needed Internet addresses from which protocol, developed at the University of Michigan and later 
product information may be obtained by sending a request further developed by Netscape Communications Corp. pro- 
message containing one or more universal product codes (or vides both access and update capabilities, allowing directory 
company codes) to the cross-referencing server and receive 35 information to be created and managed as well as queried, 
in return a list of the corresponding Internet addresses. In LDAP is an open Internet standard, produced by the Internet 
this way, the links to additional information contained on Engineering Task Force (IETF), the same body responsible 
product list pages can be refer to the manufacturer's servers ^j. creating TCP/IP, the Internet domain name service 
directly, and can suppress the creation of links when no (^^S), and the hypertext transport protocol (HTTP). The 
mformation has been made available. ^D^ p^^^^, ^^^^^^ ^ j^^s 1777 and 1778 and 

A mechanism here called "Image-cued links 'can also be informational documentation is further provided in RFC 

used to suppress the appearance on a web page of hnks to ^^^3. The use of LDAP to provide directory lookup services 

unavailable product or company information. For example, ^-^ j^^^^^^^ ^^^^^^ ^^^^^^^ ^^^^^^^^ ^ 

animage-cued link can display a graphical icon for a book , , , rr^xnu \\r^ r\\7 

i. ^. ^ . ^1.1 u- u ■ u* u -UI example, Implementing LDAP by Mark Wilcox (Wrox 

listmg on web page 334 which might be either a visible „ lr^f^X\ jt>.^ti t^- 

button with the legend "Learn More" or an invisible ^5 Press-1999 and LDAP- Programming Directory 

(transparent or single-pixel) graphic image, depending on ^^^^^/^^ Applications with Lightweight Directory Access 

whether or not the ISBN for a listed book has a correspond- Protocol by Tim Howes and Mark Smith (Macmillan Tech- 

ing URL stored at the cross-referencing server 336. Ulie nology Series^l997). Operational LDAP server software 

HTML for an image-cued link to information about the book n^^y be purchased from a variety of sources, and includes the 

identified by ISBN 0821219804 might be written like this: 50 "Netscape Directory Server*' marketed by the Netscape 

Communications Corporation. 

<a An LDAP server may be advantageously employed to 

href«"http://www.upclink.com/cgi-bin/show?isbna store "entries," each of which is uniquely identified by a 

0821219804"> distinguished name (DN) which may take the form of the 

<img 55 company code portion of the universal product code, creat- 

src="http://www.upclink.com/cgi-bin/button?isbn= ing a "flat namespace" in a single level tree structure, with 

0821219804" the remainder of the entry including a string specifying the 

border-"©** width-"51" height«*"21** URL of the server resource from which information about 

> products assigned that company code may be found. In one 

60 arrangement, an online merchant's server may send a 

where the "anchor" for the link to the CGI script named request to a remote directory server using the LDAP proto- 

"show" is an imbedded image (fetched from a different CGI col to obtain the URL at which information about a specific 

script named "button" which also executes on the cross- product is available. Next, the merchant's server could again 

reference server). The Perl script button.pl is also repro- use the LDAP protocol to fetch information about a specific 

duced in the Appendix and performs the same initial pro- 65 product designated by the remainder of the universal product 

cessing of the incoming ISBN number as the script show.pl. code from a second LDAP directory server at the URL 

Both show.pl and button.pl determine whether data is avail- specified by the first server, the second LDAP server being 
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operated by the product manufacturer to store the URL at server's IP address, it can then ask that server for permission 

which data describing particular products is stored. The to view a web page or otherwise obtain information about 
actual product data may advantageously be stored as XML the designated product. 

"documents" as discussed later. Note that the registered domain name can advantageously 

5 take the form of the company code only, with the remainder 

Product Code Cross-Referencing with Domain universal product code being passed as a parameter to 

Name Servers manufacturer's server. For example, if "123456" is the 

Cross-referencing a universal product code to the Internet company code portion of the product code, and the trailing 

address of the source of information about the product digits "7890123" designate a particular product made by that 

designated by that code can be advantageously performed by company, the assigned domain name might be "123456.upc*' 

Internet domain name servers (DNS). Conventional Internet and the full URL for the product might take the form 

domain names are symbolic names (a character string) that "123456.ean/7890123" (for a thirteen digit EAN-13 code). It 

identify different computers and resources on the Internet. would thus be up to the manufacturer's server to intercept 

While computers connected to the Internet actually use and process the product designating suffix digits "7890123" 
binary IP (Internet Protocol) addresses to find each other, " ^ identify and return information on the particular product 

people find words and abbreviations to be much more specified. Note also that different universal product code 

convenient to remember and use. The Internet domain name systems, such as the UPC codes used in the United States 

system assigns computers and resources a domain name that and Canada, the EAN codes used elsewhere in the world, a 

corresponds to the numerical IP address used to access that decimal digit universal product code drawn from the 

computer or resource. Each domain name must be unique, ^^^^^ P^ol of UPC and EAN numbers, or ISBN numbers 

and server operators register their desired domain names **sed by the publishing industry, might conveniently be 

with a domain name registration service. assigned different first level domain designations, such as 

Domain names are composed of a hierarchy of names that " ^"f! ^^^P^^tively. At the time the 

appear in descending levels from right to left. Therefore, the correspond mg to a given company code and/or 

levels that appear at the end of URLs and E-mail addresses P^°f are registered appropriate procedures may be 

are the first-level and second-level domains. For example, in confirm that the apphcant for DNS registration has 

the domain name "patentsoft.com," the suffix "com" is the ^^^^ ^^^^ned that particular code in the existing uiiiform 

first-level domain, and "patentsoft" is the second-level product code system, or has authority to act on behalf of the 

domain. By creating a new first-level domain (e.g. "upc"), ^n^^/ssignee of that code. In this way, the existing umversal 

the universal product code, or the company code portion of P.^^duct code registration authority retams primary respon- 

asetofuniversalproductcodes,couldform thesecond-level '^^^^y ^^5 ^""^f codes, whereas the DNS registrar at 

domain ^^^^ ° ^ confirm the identity of the DNS registrant. 

Note'that, if the oompany code portion umversal pioduct domain name sj^tem that is cunenUy in 
code is used as the second-level domain, registration need 35 ^'^espread use is described m RFCs 1034 and 1035. RFC 

only be done once for aU product codes sh Jing that con.- j^l^^f' '° >nt«'duct.on to the Domain Name System 

pany code. Note also that, as noted earUer. it is desirable that (^^S), and omits inany details which can be found m its 

each manufacturer respond to a request for information '=omp^^on RFC 1035 which is entitled Domain Names- 

about that particular participating manufacturer. For Implementation and Speofication. Recently, Tlie Internet 
example, retail merchants and distributors may advanta- 40 C<"P°»''°n Assigned Names and Nuinbers (ICANN), a 

geously use the company code portion of a universal product ?.T^'°^\u^T'^^'^' '"'^ 

code to access a variety of usefiil information about the ^'^^ '^'^ "P*** aUocation, protocol parameter 

company generally, including contact information and "ssigmnent, domam name system management, and root 

distributioD. shipping and discount policies. In this way, any ^'^"'^ ""^ management functions currently performed 

retailer can use the web to obtain general information about 45 U S. Government contraa by LANA and other enti- 

a company while those retailers with established accounts ''^/^?~i^"?Jy. Jjis writing, ICANN, or a new authority 

with a particular vendor (as confirmed, for example, using au'hon^ed by ICANN, wodd be the appropriate authonty to 

digital signatures) may obtain private information which b ''T* namespace for the translation of umversal 

hidden from the general public P«^"^' oompany codes) to ip addresses as pro- 

; , , , , posed here. 

In this way, universal product codes and/or company 50 ^ ^ . , 

codes can be used as domain names which are cross- The use of the domain name server system as the mecha- 

referenced to IP addresses using existing DNS facilities. "^"^ cross-referencmg universal product codes and 

Thus, when a web browser issues a request directed to a addresses is used m the illustrative embodimem of 

URL including the domain name "123456.upc," the DNS mvenUon which is depicted m FIG, 6 and described next, 

server (typically assigned by the customer's Internet service 55 j^j^g^ xML, XSIVCSS and XPointets 
provider) responds with a corresponding IP address of an 

information server maintained by or for the company des- HG. 6 of the drawings illustrates a system which permits 

ignated by the company code "123456** (assuming that computers operated by large numbers of manufacturers and 

company has registered the IP address for that company large numbers of online retailers to work together to provide 
code with a DNS registration authority). If the assigned DNS 60 shopping services to customers via the World Wide Web. 

server doesn't already have the cross-reference between that FIG. 6 shows a browser 410 being used by an online 

product code or company code domain name and the manu- shopper to view products offered by a retailer which operates 

facturer'sserver'sIPaddress, it asks the primary DNS server an inventory control system computer seen at 422. The 

that is responsible for the domain if it has the server's IP inventory control system 422 is conventional and includes 
address. If the primary DNS is busy or unavailable, it will 65 one or more conventional point of sale registers as illustrated 

ask the secondary DNS server assigned to that domain. at 421 through which sales are made to customers who visit 

When the customer's DNS server gets the manufacturer's the physical "bricks and mortar" store. In addition, however. 
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the inventory control system is provided with a "web In addition to using XSL to specify the rendering style of 

register'* which, to the inventory control system appears to XML data, cascaded style sheets (CSS) can also be used as 

fimctioQ in the same way as a conventional point of sale set forth in the Proposed Recommendation dated ^r. 28, 

register but which, in fact, operates through a sales server 1999 from the World Wide Web Consortium (see http:// 

430 which provides Internet services on a shared basis to 5 www.w3.org/TR/1999/xml-stylesheet-19990428). This 

multiple retail stores and their inventory control systems. A specification allows a stylesheet to be associated with an 

communicationspathway connects the web register 420 and XML document by including one or more processing 

the inventory control system 422 to the shared sales server instructions with a target of "xml-stylesheet" in the docu- 

430, with the inventory control system 420 supplying the ment*s prolog. The World Wide Web Consortium's rccom- 

product codes and corresponding oo-hand quantities as mendation regarding cascaded style sheets may be found at 

indicated at 432 and receiving from the shared sales server http://www.w3.org/TR/REC-CSSl (Jan. 11, 1999) which 

order information as indicated at 434. specifies level 1 of the Cascading Style Sheet mechanism 

A product information server 423 supplies product infor- (CSSl). CSSl is a simple style sheet mechanism that allows 

mation to the browser 410 in the form of XML data as authors and readers to attach style (e.g. fonts, colors and 

indicated at 424 in response to requests 425. The browser 15 spacing) to HTML documents. The CSSl language is human 

410 preferably utilizes the Internet domain name system as readable and writeable, and expresses style in conomon 

proposed above to convert incoming universal product codes desktop publishing terminology. One of the fundamental 

into Internet addresses, with the domain name system con- features of CSS is that style sheets cascade; authors can 

sisting of an assigned domain name server 470 which attach a preferred style sheet, while the reader may have a 

receives universal product codes in address requests 472 and 20 Personal style sheet to adjust for human or technological 

returns the registered Internet addresses 474 to the browser handicaps. Thus product descriptions as viewed on the 

410. When needed, the assigned domain name server 470 browser may include content from the product manufacturer, 

obtains the registered cross-references between universal reflect a preferred rendering style specification from the 

product codes and IP addresses from the primary DNS 476 online reseller, as well as the personal style preferences of 

or from the secondary DNS 478. 25 viewer. 

The shared sales server 430 sends web pages 438 con- XSL could alternatively be used at the shared sales server 

taining information about products available from a con- 430 to transform XML data fetched by the server 430 from 

nected retailer to the browser 410, along with XSL the manufacturer's server 423 and then converted into 

(Extensible Stylesheet Language) or CSS (Cascaded Style KVML documents with CSS style sheets at the sales server 

Sheets) style specifications as seen at 440. The use of XML 30 430, This has the benefit of being backwards compatible 

and XSL or CSS provides several advantages. First, the with browsers which do not include the ability to handle 

selection and rendering of the product information is con« XSL/CSS. Alternatively, XSL conversion can be performed 

trolled by the links specified in the web page 438 as on the server 430 to transform XML data into XML docu- 

produced by the sales server. For example, if the web page ments with CSS style sheets. XML, unlike HTML, comes 

438 contains a product listing web page created in response 35 with no formatting conventions and will always need a style 

to a search request from the browser 410, each included sheet to be displayed. This method requires that the browser 

product description may include a link to only an that have the ability to use CSS to render XML. A third alter- 

porlion of an XML product description which contains a native is to use XSL to generate HTML/CSS on the client 

brief product description and a thumbnail image of the listed side, a method which requires that the browser have the 

product, whereas, in response to a customer's request for 40 ability to directly use CSS and XML, which older browsers 

more detailed information, the sales server may return a web cannot do. Finally, the browser may transform XML and 

page containing an XML "Xpointer" link to detailed product XSL into "CSS formatting objects". Compared to the pre- 

information and/or to an enlarged image of the product. In vious method, this method is more direct as the content isn't 

both cases, the style in which the XML data is rendered by converted to/from HTML. 

the browser (e.g. typeface, font size and color, background 45 The ability to select only a portion of an XML product 

color, etc.) is controlled by the style specification supplied description document for reproduction on a web page is 

by the sales server 430. In this way, the same XML data may provided by the Xpointer protocol. As explained in the 

have different visual styles when included on the pages World Wide Web Consortium Working Draft of Mar. 3, 

created by different retail vendors. 1998, at http://www.w3.org/TR/WD-xptr, the XML Pointer 

llie XSL (Extensible Stylesheet Language) consists of 50 Language pCpointer) document specifies a language that 

consists of two parts: (1) a language for transforming XML supports addressing into the internal structures of XML 

documents, and an XML vocabulary for specifying format- documents. In particular, it provides for specific reference to 

tingsemantics. An XSL stylesheet specifies the presentation elements, character strings, and other parts of XML 

of a class of XML documents by describing how an instance documents, whether or not they bear an explicit ID attribute, 

of the class is transformed into an XML document that uses 55 Using Xpointer, only selected portions of an XML product 

the formatting vocabulary. XSL is described in the World description made available from the manufacturer's server 

Wide Web Consortium's "Extensible Stylesheet Language need be presented on a given web page, enabling the creator 

Specification," the current working draft of which may be of the web page which links in XML data to control the 

found at http://www.w3.org/TR/WD-xsl (Apr. 21, 1999). An nature and extent of the information shown, 

XSL stylesheet processor accepts a document or data in 60 The manner in which explicit relationships between two 

XML and an XSL stylesheet and produces the presentation or more data objects, such as a retailer's product list page 

of that XML source content as intended by the stylesheet. It and the product informatioo about a product listed on that 

is contemplated that most major web browser applications page, may be expressed as a link asserted in elements 

will include XSL stylesheet processors which will enable contained in XML documents. These "XLinks** in the sim> 

them to convert the combination of XML and XSL data into 65 plest case are like the HTML links described above in that 

a form, such as a viewable HTML web page, as specified by they are expressed at one end of the link only, are initiated 

the XSL. by users to initiate travel to the other end of the link, gp only 
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to one destination (which may be determined by a DNS allows metadata authors to use multiple inheritance to mix 

server or by an independent cross-referencing server), and definitions, providing multiple views of ±eir data, and 

produce an effect which is mainly determined by the leveraging the work done by others. From a practical 

browser. The functionality of links is being vastly extended, standpoint, the creation of a simple and generic product and 

however, by the XML Linking Language (XLink) specifi- 5 company description base schemas which can thereafter be 

cation being developed by the World Wide Web Consortium extending using RDF allows basic information about prod- 

and available at htlp://www. w3.org/TR/WD-xlink. As ^cts and companies to be made available early, allowing 

extended, the XUnk specification wiU provide more sophis- ^^ore elaborate schemas to evolve as experience with the 

ticated multi-ended and typed Imks which can be used to • ^ ^^^^ 3 ^^^-^ ^^^^ 

advantage to automatically incorporate Imked-m product mTT i. i.- u c i_ 

informadon from one or more manufacturers into dispUys " , "^."^^ these techmques, the product manufacturer may be 

and multimedia presenUtions presented by retailers and ^^^ly freed from concerns about web page design, format- 

Others *- ^ ^jjg mtegration with other information, and may con- 

^ * . 1 J. J . jj... . c centrate on providing accurate and up-to-date text descrip- 

M previously discussed, m addition to the use of a its product, along with whatever images best 

product code translation Utility which cross-references all or , u .u j * • i.u • ♦u ^iZ*- 

^ ^ , J , ^ - - .15 descnbe the product, simply by registenng the relationship 

part of a universal product code mlo an Internet address, it . ^ ^, c ^ j -1 

!^ , , , , *\ . , , . . between the manufacturers company code and/or umversal 

is desirable to establish a protocol or convention which , . ^ / \ »u • * ♦u r^n^... 

•r,.icc product codefs) with the appropriate authonly, and foUow- 

enables a requester to specLQC kinds 01 miormation about ... « ui- u -1 » * *c *• f .il • r 

_, ^, , ^ , , ,™,T mg the established content specifications for the mformation 

Identified products or companies. In a conveDiional HTML ^^.^^ manufacturer makes available at tbe registered IP 

system, this can be done by establishing naming 20 address 
conventions, as described above, for selectively locating 

different kinds of information about a product designated by should be noted that XML, XSL, Xpomter, XLink and 

a given universal product code, as well as different kinds of related Internet protocols and specifications are still being 

information about the company identified by the company ^^^^^ extended, a process that can be expected to 

code portion of the product code. „ enhance the abihty of the present invention to selectively 

TTie metadata capabilities of XML can be used to advan- ^^/^ attractively provide information about products to those 

tage to provide an extensible system for dividing product ^f.^^f ^^^^ mformation from the most knowledgeable 

and company information into a hierarchy of nested named information, 

elements which can be selectively accessed. Using the ^h^ ^^^^^ g^j^^ g^^^^ uy^^^ Register** 
Document Type Descriptor (DTD) component of XML, the 30 

makeup of the required and optional components of such Conventional retail stores display merchandise for pur- 
information can be defined in a standard way, facilitating the chase in physical showrooms for inspection and purchase by 
definition and validation of data structures to be used on consumers. These stores typically obtain the products they 
various classes of products. sell from a large number of manufacturers, either directly or 

The World Wide Web Consortium has further defined the 35 through distrftjuiors. Computerized inventory control sys- 

"Resource Description Framework (RDF) and Syntax terns are used to keep track of orders and sales in an effort 

Specification" as described at http://www.w3 .org/^fR/REC- to insure that goods are available for prompt delivery to 

rdf-syntax. RDF provides a foundation for processing meta- customers when purchased while minimizing the expense of 

data (i.e. "data about data") and provides interoperability the maintaining an unsold inventory of products. Barcode 

between computers that exchange information on the Web. 40 checkout and EDI (Electronic Data Interchange) systems are 

Using RDF, data about products and companies, which can commonly used in combination with inventory control sys- 

be accessed in accordance with the invention by using tems to automate sales transactions. Customer checkout 

universal product codes; can be used by search engines to counters equipped with barcode readers automate the cus- 

provide access to such information, can be used to auto- tomer sales transaction, reducing errors and reducing costs, 

matically catalog the content and content relationships at 45 EDI, the computer-to-computer exchange of business docu- 

particular web sites, pages or libraries; can be used by ments in a standard format, automates transactions between 

intelligent software agents to facilitate the sharing and the retailer and its suppHers by transferring sales documen- 

exchange of information about companies and products. tation in electronic form, including the purchase order, the 

Using RDF with digital signatures, the privacy preferences invoice, and the advance ship notice. Barcode readers and 

and policies of the owners of product and company infor- 50 services are now commonly used even by smaller 

mation can be selectively protected to help buUd the "Web retaUers and have significantly reduced the cost of doing 

of Tmst" needed for electronic commerce. busmess. 

ImporlanUy, RDF provides a mechanism for defining 1° ^^cent years, the Internet has produced new on-line 

metadata in a class system much like the class systems used sales mechanisms which promise to revolutionize retail 

by object oriented programming and modeling systems. 55 sales. Using the World Wide Web, both manufacturers and 

Classes are organized in a hierarchy, with a collection of resellers offer products to consumers for direct purchase 

classes used for a particular purpose (such as the collection with product delivery normally being accomplished by mail 

of classes describing a "product" and/or the collection of or a commercial delivery service. The consumer typically 

classes describing a "company") being called a "schema." employs a web browser to search for products of interest and 

RDF thus offers extensibility through subclass definition. 60 display product descriptions. Customers make purchases by 

For example, creating subclasses for a particular kinds of completing one or more displayed forms to provide needed 

product (e.g., publications, software, foods, clothing, etc.) information (e.g. a credit card number and a shipping 

requires only incremental modification of a base "product" destination address). 

schema, and each such subclass may then be further modi- Many successful web resellers take advantage of the fact 

fied to form descendant schema for even more particular 65 that a web presence is inherently world-wide, and that the 

kinds of product (e.g., magazines, video games, cereals, delivery charges of many services are largely independent of 

shirts, etc.). The shareability and extensibility of RDF also distance. Because a physical showroom is an unnecessary 
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expense, web resellers can often successfully sell at much the quantity on hand. When the quantity on hand equals or 

lower cost directly from one or more warehouses. To be exceeds the quantity ordered, the on line order is accepted 

successful, however, such a web reseller must make its and passed at 434 from the shared server to the web register 

presence known to a large audience. As a result, large and module 420 which posts the sale in the same way that a point 

well-funded web reseUers capable of effectively marketing 5 of sale register posts a sale. The fact that the web register 

on a nationwide scale have done well while those which '*20 performs the same fiinctioos as a conventional cash 

have attempted to market their offerings locally or not at all register enables the conventional inventory control system 

have predictably been much less successful. ^22 to function in the normal way with the exception that 

., , , , It must also update the product code and quantity on band 

Urge chain reseUers with many reUi] oulleu have also data maintamed by the shared server. TTie fact that the shared 

estabhshed successful web sales operations. Because the lo „j^^„ ^ ^^^^ ^^^^ ^^^^^ 

cost of creatmg and maintammg a web presence, as weU as jo accurately inform the customer w hen shipment can 

the cost of nationwide marketing, can effectively be shared b e-e ^neded tor good s on hand ISB^ hen goods vfeh mi^ 

among many retail outlets and becau^ much of the infra- be-f^iTb^ ^11 be shipped with a delay. Orders sent to 

structure needed to provide order fulfillment is already in aie inventory control system at 434 indude the specification 

place, such diainaores compete well with the nationwide « ^^^^^^^^ ^^^^ ^^^.^ rxnivctstl product code 

weo-only mercnants. designation) and the quantities of each sold, as well as 

Although customers would often benefit from the conve- address information for billing and shipping. Credit card 

nience of reviewing and ordering products from a local transactions are handled on a shared basis using standard 

reseller, individual retail stores and smaller, local chains ecommerce software, either by sending encrypted credit 

have tj^ically been unable tojustify the cost of creating and card and other billing information to the retailer for 

maintaining a web sales system. In addition to the substan- handling, or actually performing the monetary transaction 

tial cost of installing and maintaining the needed hardware with the customer in its entirety on the shared server, and 

and software, the website owner must expend significant sending periodic payments and accounting records to the 

effort to create and periodically update the product descrip- retailer. 

tions which customers require in order to make informed importantly, functions better performed by the retail store 

purchases. The annual cost of operaUng a merchant website u^i^g resources best shared with the physical store's opera- 

often far exceeds the revenue which the local merchant tions are not performed by the shared server 430 but rather 

would derive from the hmited probable volume of onhne ^y the store's inventory control system 422. Such fimctions 

30 include order fulfillment, inventory pricing, vendor 

The infrastructure depicted in FIG. 6 permits smaller and ordering, reordering and payment, and warehouse manage- 

mid-sized merchants to profitably and efficiently offer online ment functions. 

ordering services to their customers. By using the cross- Examples of merchant server software which may be used 
referencing capability provided by the present invention, to implement the shopping basket and credit card transac- 
which provides customers with reliable product inforaiation 35 tions performed by the shared server 403 include the Soft- 
direct from the manufacturer, and the shared sales server 430 Cart system offered by Mercantec, Inc. SoftCart 4.0 includes 
and web register 420 which provides shareable functions integration to the CyberCash system for credit card trans- 
which effectively connect the retailer's existing inventory actions and includes a Software Developer's Kit to enable a 
control system 422 to the Worl^ Wide Web, the cost and programmer to integrating SoftCart with WWW programs 
complexity of retail web sales is largely eliminated, and the and legacy systems. A discussion of available systems and 
consumer obtains the convenience of shopping by computer techniques is found in Designing Systems for Internet Com- 
with the other advantages of shopping with a local merchant. ^erce By G. Winfield Treese and Uwrence C. Stewart 

The shared sales server 430 operates in the same way and ISBN: 0201571676 (Addison Wesley 1998). 

provides the same functions as a conventional online mer- \^^^|) In accordance with the invention, neither the shared server — ^ 

chant server: it enables customers to perform searches of 45 430 nor the retail inventory control system 420 need store or / 

available products and produces listings which the customer maintain descriptive information about products. Whenan / 

can review, with the ability to click on individual items to o nline custome n- desiresinformatipn about a given product , 

activate links to additional product information from the i f is obtai ned for^yie wby the customer using XM L 

manufacturer's server as noted eariier. In addition, the Xpointer HnRTto the manuTac turer's server. XML infonna - 

shared server provides "shopping basket" and credit card 50 ti on is located by supplyinglErumveSaTproSuct code fo ? 

transaction services to enable the customer to complete the product to theJMS.se rver 472 which stores product code 

purchases. tgJntcrn et address conversion i nf prmatinn P roduct searches 

The shared server 430 and the web register module 420 w hich loca t e products offe red b y a given retailer (as revealed 

added to the retailer's existing inventory control system 322 by t he product coae ana quantitx^oxyiaad^taja^aseyaye, 

maintain a connection via the Internet or a dial-up modem 55 disp kyed Jg ike .c'lji^^iera nd , to the e^xtent Ihey resultin 



pathway which permits the inventory control system 422 to pui rcTiases, are mani^^ the transmission of a com - 

upload to the shared server 430 changes to the products pie ted order to the retailers inventory control a stern. _ 

(specified by universal product code) being offered for sale, In a typical shopping transaction performed on the system 

and the quantity on hand. Each time any sale is made by any shown in FIG. 6, a shopper employs the browser 410 to visit 

point of sale register 421 in the physical retail store or by the 60 a web site which executes on the shared sales server 430. 

web register 422, the quantity on hand value associated with When 4he shopper reviews an HTML web_Dagc which lists 

the sold product's code is altered. Similarly, when stock is av ailable products, as illustrated at 438 in FIG. 6, the 

replenished, the inventory control system 422 reflects the shop per can request additional information on an v listed 

increased quantity on hand. The quantity on hand informa- prQduct_by_ using~tbe browser 410to chckon a linK anch or 

tion passed as message information at 422 permits the 65 oiu the pager438, t he reby issuLng are request 472 tolEe 

shared sales server to maintain a database for each retailer d omain name server 470 for the IP address at_w liic6-addi^ 

served which indicates the products available for sale and tional information on that product identified by a univecsaj 
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product code which forms part of the URL contained within 
the r cgucsi 472. The DNS 470, consulting a primary DNS 
476 or secondary DNS 478 if necessary, returns the IP 
address to the brmv ifr 41ft ^vhirh then itifnift^ a '•"i"?rS' 4«n 
for XML product mionnaiion lo the product information 
server 422 maintained by the manufacturer of that product. 
Using the XSL stylesheet specification 440 supplied by the 
shared server 430 (in accordance with the background 
colors, font styles, etc. which may be characteristic for the 
web presence of the specific retailer), the browser presents 
the product description contained or sp ecified by the XML 
data 424 to the use n ^ 

If the user decides to purchase the described product, the 
"shopping basket" functions of the shared sales server 430 
are used to complete the order. Because the shared server 
430 maintains a database for that retailer containing the 
quantity on hand values for each product offered by that 
server, the customer can be immediately informed if the 
shipment cannot be made whereas, if the product is available 
at the retailer's store or warehouse, the online customer's 
order can be confirmed for prompt delivery. When the order 
is completed by the shared server 430, the order 434 which 
includes the identification of the customer (name, shipping 
address, etc.) and the identification of the products sold 
(universal product codes plus quantities sold) is transmitted 
to the retailer's inventory control system 420. As explained 
in more detail below in connection with FIG. 7, the shared 
server 430 adjusts the quantity on hand values in its 
database, and the inventory control system 420 updates its 
database, with a cross check between the two being made if 
desired to insure consistency and synchronization. 

It is important to observe that the arrangement shown in 
FIG. 6 isolates the retailer from substantially all of the 
concerns normally associated with the creation and mainte- 
nance of an online sales website. In accordance with the 
invention, the retailer need not be concerned with the 
creation or maintenance of accurate information on the 

products sold, since that task is appropriately born by the 

product manufacturer which has that information. Similarly, pro cesses online orders fromlhe sharea server (seen at 430 
the retailer need not be concerned with the creation, hosting, 40 iirfKj7"6)~in the same way. llie unit~503~maintains the 

visibility of those orders until shipment is completed by 
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s^tem, nai ich in the same way as a convc ntinnal-Dnint-of 
s^{ejteimS3rThe other components of the inventory control 
system include essentially conventional purchasing, 
r ^ejving, o j^r processing, shipping and invoicing fun c- 
tions described~in the hterature. SeCj ioTexample, the texts 
Best Practice in Inventory Management, by Tony Wild, John 
Wiley & Sons; ISBN: 0471253413 (March 1998) and/rtwn- 
tory Control and Management by C. D. J. Waters, John 
Wiley & Sons; ISBN: 0471930814 (June 1992). 
j\0!y Within the inventory control system, the purchasing mod- ' 
ule 501 presents printed reports and screea,digilays^\vhich 
assist^ purchasing ageats to see which products need to b e 
orders dand which vendors ne 6d,tQ-b 6_contacted to followu p 
on p rior orders, and automates back orders and reorders . The 
m5dule 502 generates purchase orders, and alerts purchasing 
agents of urgent or routine product ordering needs by 
evaluating supplies on hand and estimating the demands for 
each product to determine if supply levels will fall below the 
predetermined minimum stock quantities established for 
each product by the merchant. The purchasing module 501 
further creates planned orders based upon a minimum order 
qu antity , ord er multiple , yie ld percent age and maximum 
plan,quatttitics established by the merchant, and^lters the 
purch aser, o f low product levels automatically. Purchase 
Orders are generated using screens presented to the purchas- 
ing. agentwhichc an re call vendor p rice HstsTincluding price 
breaks and special promotion pricing. These purchasing 
functions are typically performed in a bricks-and-mortar 
retail store or group of stores, and need not be ahered to 
support online sales as contemplated by the present inven- I 
tion. 

Similarly, the receiving module 502 accepts inventory 
control information by capmring data describing incoming 
orders from vendors, issues inbound receipts and purchase 
order confirmations, and tracks back orders. Inbound 
receipts are generated from existing Purchase Orders 

The order fulfillment unit 503 accepts both conventional 
sales orders of the type received by mail or telephone, and 



and maintenance of a reliable and easy to use online shop- 
ping experience, a task performed by the shared server 430 
for many different retailers. To the retailer, the shared server 
presents an interface to the inventory control system 420 
which behaves much like conventional point-of-sale termi 
nals (cash registers) indicated at 421. 

This "web^ register '^ c apability can adv9 n'^ g^""*^1y 
inst alled and maintained , with trammg being provided to the 
retailer, by inventory control system vendors as part of the 
normal inventory control system software, maintenance and 
training. The shared server functions can advantageously be 
made available by an independent Internet service provider 
(ISP) usi ng standard e-commerce software , and the inde- 
pendent vendor of the shared sales server software can 
provide interface specifications and software support to the ^5 
inventory control system vendors, e nablin g them to addjh e 
necessary "web register" interface functions to agy or 
existing Inventory control systems . In this way, each func- 
tion is performed by anentity which is already experienced 
in that phase of the overall system requirements, and each go 
function is provided at little additional cost over costs 
already born by eadi contributor. 

Hie relationship between the shared sales server seen at 
403 in FIG. 6 and the retailer's inventory control system 
seen at 420 in FIG. 6 is shown in more detail in FIG. 7 of 65 
the drawings. As discussed above, the remote shared sales 
server operates, from the standpoint of the inventory control 



identifying orders that need attention, including orders that 
must be rescheduled or expedited, to insure prompt delivery 
and to provide order status information to the customer. 
Customer contact information (phone number, email address 
or mailing address) from the online shared sales server 430, 
like similar information obtained by telephone or mail, may 
be used to automatically issue email notifications or assist 
the merchant in contacting the customer in other ways to 
confirm or reschedule orders. 

The shipping module 504 is also conventional, and 
handles outbound shipments, accepts new customer ship- 
ping and biUing address information, handles partial ship- 
ments by identifying items reserved for later shipment, and 
prints packing slips and bills of lading. 

The invoicing module 507 provides invoicing, billing and 
charging capabilities, printing invoices to be sent to cus- 
tomers. The shared sales server may support billing in 
several ways: it may simply send orders to the invoicing 
module 507 including shipping information supplied by the 
customer using HTML forms; it may verify and accept credit 
card information and transmit that to the invoicing module 
507 so that the actual credit card transaction is between the 
customer and the retailer, or it may complete the credit card 
transaction at the shared server, forwarding collected funds 
together with accounting information to the retailer on a 
periodic basis. 
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It is a principle feature of this aspect of the invention that Consumers and the general public access information and 
the retail merchant, who already maintains a physical inven- perform transactions via the Internet using conventional web 
lory and/or a distribution relationship with manufacturers, as browsers (i.e. conventional web browser application pro- 
well as an inventory control system for managing its inven- grams executing on desktop computers or workstations) as 
tory and distribution functions, perfonns the order fulfill- 5 exemplified at 803, 804 and 805. Such web browsers typi- 
ment function using facilities which are shared with those ^ally employ a shared Internet Service Provider (ISP) as 
used by conventional "showroom" sales facility. The shared indicated at 807 which provides a connection to the Internet 
sales server merely processes data, and need not be con- 

cerned with the actual selection, purchase or distribution of ^ . 1 - ^ • , 

physical products, nor with the creation of the detailed These consumers may view product mformation and 

product information needed by the consumer when making perform sales transactions as contemplated by the present 

online purchases. Both of these functions remain where they invention by viewing information made available by retail 

are best performed, with the retailer and the manufacturer stores 8U, 812, 813 and 814 via a shared sales server 820, 

respectively. as well as by a server 825 operated by a single retail store 

• When sales arc performed using conventional point of (or chain of stores). The servers 820 and 825 transmit web 

sale terminals as indicated at 508, a sales module 510 pages to the web browsers 803^05 which include links to 

processes the information. The point of sale terminals 508 product information which is made available by manufac- 

perform automated sales checkout using a bar code reader to turers 831, 832 and 833 via a shared product information 

reduce errors and speed customer checkout times, enabling server 840, and from a server 845 operated by a single 

salespeople to focus more on customer service. Sales are manufacturer. 

manifested by the identification of goods and quantities 20 manufacturers preferably provide product informa- 

purchased and these are reflected in the actual delivery of ^^eir connected server in the form of well-formed 

goods at the point of sale termma which, in turn are posted extensible Markup Language (XML) documents which may 

to decrement he on-hand quantity values for the products ^^j.^^^^^ ^ ^^J^^^^ Document Type Definition 

mamtamed m the mventory control database 500. If selected /r^^^x . i. - t. n u j . • r . • j 

products are unavailable al: the point of sale, a terminal 508 25 ^P™j 'f'''^ '1 ^""""^ mformation documents 

may commonly be used to place an order for future deUvery ^*^^°^f ^^^^^ ^}'^\ documents 

to an identified customer by posting the order into the ^^^^'^ "^^y advantageously expressed in the Resource 

database 500 for handling by the purchasing module 501, Description Framework (RDF) and Syntax Specification, as 

receiving module 502, order fulfillment module 503, ship- "^^^ c^tUct, to facilitate the evolution of standardized 

ping module 504 and invoicing module 507. ,0 content definitions for product and company information. 

Incoming orders from the shared sales server placed on a ^^^'^ product information server illustrated at 840, in 
"web register" are processed in substantially the same way. ^"^P f^"^' ^^^^ nothing more than make Internet 
The order information is obtained from the customer, typi- f ^^^ssible data storage space available where smaller manu- 
cally using HTML forms, by the web sales unit seen at 521 ^^^^^^^ ^^1^°"^ ^!*^^ f^^^^ P^°^"^^ 
in FIG. 7, and the resulting order in the form of customer 35 ^°^P^°y information available via the Internet Even the 
information, product identification and quantity sold, and f""^^^^^ manufacturer can thus make product and company 
related order information is transmitted via the communi- information available to consumers and retailers worldwide 
cations interfaces 531 and 532 at the sales server and the f insignificant incremental cost. Many such small manu- 
remote inventory control system respectively. The commu- ^t''^'''' T ^'"^^^^ ^""l""^ space provided free of 
nication Unk 544 advantageously takes the form of an 40 charge by their existing Internet Service Provider for prod- 
Internet link between the retailer and the remotely located company informaUon storage, 
sales server which operates on a transaction by transaction Manufacturers are not, of course, restricted to providing 
basis. Note that, because both product identification data and such product information through links from web sites of 
on-hand quantity information is available in the database retailers and others. A manufacturer may use the same 
540 at the shared server, the two can continue to work 45 information to support its own promotional web site offering 
without continuous connection, with orders taken at the such things as product directories, press releases, direct sales 
"web register" being transmitted on a batch basis, and with to consumers, and any other function and service typically 
changes to the database of offered product universal product provided by a manufacturer's web site. Indeed, by using a 
codes and on-hand quantities being posted on a batch basis predetermined URL syntax, such as http://cocode.ean/ 
from the inventory control system to the shared server. 50 homepage (where "cocode" is the company code assigned to 

The sales module 510 processes orders from both the ^^^^ manufacturer), the home page of the manufacturer of 

point of sale terminals 508 and from the shared sales server. P^^^^t can be readily accessed if that product's uni- 

It packages the customer information and the product and "^^^^^ product code is known. 

quantity sold information for handling by the remaining The availability of company information, which may be 

modules as discussed above, and schedules multiple deliv- 55 accessed using the company code portion of a universal 

eries as needed when an order can only be partially fulfilled. product code, also makes it possible for retailers to readily 

When web sales are made, on hand quantities are immedi- obtain specific information needed to purchase products 

ately reserved and, if desired, sales of the same products directly from manufacturers, establish accounts, identify 

from inventory via the point of sales terminals 508 can be distributors, and the like. The company information which is 

inhibited (although, in practice, if removal of items from the 60 "^ade available as contemplated by the invention may be 

showroom is needed to fill web orders, that should be done used to automatically establish EDI connections and per- 

promptly to avoid customer confusion). form EDI transactions between the servers operated on 

Hie relationship between retail stores, manufacturers and behalf of retail stores and those operated on behalf of 

distributors, product information services and consiuners, manufacturers. 

and the computers connected to the Internet which utilize the 65(V]Us illustrated at 875 in FIG. 8, the cr^S;referencing 

invention to serve each of these entities, is depicted in FIG, s erver can be used to by an indeyjgp^^ gervic e^'tQ - D r a v ide " 

8 of the drawings. searchable^product and company mtOffflatiOn indices and 
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s^urr^ rapahiHf^Yili nnt^H earlier, cross-referencing utility ^ 
seen at 880 in FIG. 8 may advantageously provide m eans for / 



accessing the entire content s of its cros s^i:efegencing4nfor 
mationl o a l equestiHg u>iaputer, such as a search cDgm e 
operated'bv the ipd ex^scrvicc seen at which canlhen pcrtonp 
conventional "web "crawler" indexing of the websites speci- 



fiecTby the Ustcd URLs and/or IF addresses , thereby gener- 
ating complele or i^ditial indexes to all or less than all of the 
products whose product description locations have been 
registered. Altematively, web crawling engines can traverse<i 
the links to manufacdirers' information found in product i 
listing pages made available by retaUers and others. J 

By storing product and company information in accor- 
dance with predetermined schemas, preferably using XML, 
DTD and RDF techniques as discussed above, indexing 
services can provide consumers with powerful tools for 
locating products having selected attributes and for sorting 
and comparing product based on those attributes. In this 
way, a consumer can more readily identify particular prod- 
ucts which best suit her needs, can view detailed, accurate 
and up-to-date promotional and specification information on 
each product directly from the manufacturer, and can then 
identify the most desirable retail sources for selected prod- 
ucts based on price, geography or other criteria. In this way, 
"bricks and mortar" stores can make their entire existing 
inventory available for inspection by simply adding a "web 
register** module to connect their existing bar code checkout 
and inventory control system with a shared sales server, 
providing their local customers to "shop at home," make 
purchases on line, and either pick up or arrange for local 
delivery of the goods purchased. 

It should be understood that the methods and apparatus 
described above are merely illustrative applications of the 
principles of the present invention. Numerous modifications 
may be made by those skilled in the art without departing 
from the true spirit and scope of the invention. 
What is claimed is: 

1. The method for disseminating product information via 
the Internet which comprises, in combination, the steps of: 

establishing a cross-referencing resource coimected to the 
Internet which includes a database containing a plural- 
ity of cross-references, each of said cross-references 
specifying the correspondence between a group of one 
or more universal product code values and the Internet 
address of a source of information which describes the 
products designated by said group of one or more code 
values, 

transmitting via the Internet a Web page containing at 
least one hyperlink including a reference to separately 
stored information, said reference including a particular 
universal product code value that uniquely designates a 
selected product, 

employing a Web browser program to receive said Web 
page and display said Web page to a user, 

further employing said Web browser to respond to the 
activation of said hyperlink by said user by transmitting 
a first request message to said cross-referencing 
resource, said first request message containing at least 
a portion of said particular universal product code 
value, 

processing said first request message at said cross- 
referencing resource by referring to said database to 
identify the particular Internet address which corre- 
sponds to said particular universal product code value 
and returning a redirection message to said Web 
browser which contains said particular Internet 
address; 
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employing said Web browser to automatically respond to 
said redirection message by transmitting a second 
request message to said particular Internet address; 

employing a Web server connected to the Internet at said 
particular Internet address to respond to said second 
request message by returning product information 
describing said selected product to said Web browser, 
and 

employing said Web browser program to automatically 
display said product information from said Web server 
to said user. 

2. The method set forth in claim 1 wherein said portion is 
the company code portion of a said particular universal 
product code and wherein said particular Internet address 
specifies the location of an Internet resource operated on 
behalf of the manufacturer specified by said company code 
portion. 

3. The method set forth in claim 1 wherein said informa- 
tion describing the product designated by said particular 
universal product code is expressed in extensible Markup 
Language. 

4. The method set forth in claim 2 wherein said informa- 
tion describing the product designated by said particular 
universal product code is expressed in extensible Markup 
Language. 

5. Apparatus for delivering product information via the 
Internet which comprises, in combination: 

a first computer connected to the Internet for producing a 
web page containing at least one hypertext link to 
product information, said hypertext link containing a 
reference which includes at least a portion of a par- 
ticular universal product code which designates a par- 
ticular product, 

a second computer connected to the Internet for main- 
taining a cross-referencing database storing informa- 
tion and operating as a cross-referencing resource 
which associates universal product codes and corre- 
sponding Internet addresses identifying remote 
resources fi-om which data may be retrieved which 
describes the products identified by said universal 
product codes, said second computer including means 
for responding to a request message containing a least 
a portion of a given universal product code by trans- 
mitting a response message specifying the correspond- 
ing Internet address from which information describing 
the product designed by said universal product code 
may be retrieved and to which said request message 
should be redirected, and 

a third computer connected to the Internet for executing a 
web browser program, said web browser program com- 
prising 

means for retrieving said web page from said first 
computer, 

means for identifying said hypertext link in said web 
page and transmitting a first request message to said 
cross-referencing resource, said request message 
containing at least a portion of said particular uni- 
versal product code to obtain from said second 
computer a response message specifying a particular 
universal product code to which said first request 
message should be redirected, and 

means automatically responsive to the receipt of said 
response message for transmitting a second request 
message to said to said particular Internet address to 
retrieve product information describing the product 
designated by said particular universal product code, 
and 
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means for receiving and displaying said product infer- tained in a predetermined standard XML Document Type 

malion relumed to said third computer in response to Definition for product information, 

said second request message. 12. The apparatus set forth in claim 10 wherein said 

6. The apparatus set forth in claim 5 wherein said response product information conforms to a schema expressed in 
message takes the form of a hypertext transport protocol 5 ^^^^^dance with the Resource Description Framework 
response message which mcludes a location header held fRDp) and S ntax S cification 

containing a destination URL specifying said particular ^ . 

Internet address whereby said request message is redirected ^he apparatus as set forth m claim 5 wherem said 

to said particular destination URL. reference m said web page is contamed in a hypertext link 

7. The apparatus set forth in claim 5 wherein said database 10 anchored by a visual element which is retrieved from said 
stores a company code portion of a said universal product second computer by said web browser program when said 
code and wherein said corresponding Internet address speci- web page is displayed, said visual element having content 
fies the location of an Internet resource operated on behalf which is dependent upon the nature of the information stored 
of the entity specified by said company code portion. i^, g^id database relating to said particular universal product 

8. The apparatus set forth in claim 5 wherein said cross- 15 ^^^^ 

referencing resource is the Internet Domain Name Service. ^ .r.^-i iit.- j 

n ^ ^ *r_*u-i ou- J J. 14. The apparatus as set forth in claim 13 wherem said 

9. The apparatus set forth m claim 8 wherein said product . , , . ^, . ^ .j ,^ 

information is expressed in extensible markup language. ^^^^^ ^^^"^^"^ ^ ^"^^g^ transmitted to said web 

10. The apparatus set forth in claim 9 wherein said web browser from said second computer in response to an image 
browser displays said product information in accordance 20 request message containing at least a portion of said par- 
with stylesheet information specified on said web page. ticular universal product code. 

11. The apparatus set forth in claim 10 wherein said 

product information satisfies the validity requirements con- ♦ » ♦ * ♦ 
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NETWORK-BASED SYSTEM FOR THE evaluate the design acxx>rding to their various engineering, 

MANUFACTURE OF PARTS WITH A business and management specialties. Typically, there will 

VIRTUAL COLLABORATIVE be a management team whose primary function is to ensure 

ENVIRONMENT FOR DESIGN, that the development program is "on schedule'* and "on 

DEVELOPEMENT, AND FABRICATOR 5 cost/' There will be a business/accounting team who will 

SELECTION analyze the costs of the development program and the 

expected costs of the product produced in quantity. There 

RELATED APPLICATIONS will be a series of engineering teams, each of a particular 

^ discipline or specialty. In our sonobuoy example, there will 

Tills application is a contmuau^^^^^ apph- be mechanical engineers, electrical engineers, RF engineers, 

cation Ser No. 09/270,007, ^ed Mar. 16, 1999, entiUed ^^^^^ speciali^, reUability engin^, safety eniineers; 

Interactive System for Engineering Design and ^^^^^ pnjcessing specialists, production engineers and so 

Manufacture," and U.S. apphcation Ser. No. 09/311,150, ©n 

filed May 13, 1999, entitled "Network Integrated Concurrent \. ^ r i. -i, , t. ^ - 

Engineering With Computer Aided Design," both of which Each of these teams will evaluate the design (three 

are herein incorporated by reference. dimensional model and assoaated specificaUons) to deter- 

mme conformance with requirements. In a typical develop- 

FIELD OE THE INVENTION ment effort, these teams will recommend changes to the 

design to rectify deficiencies or improve performance. The 

The present invention relates generally to a design will evolve (as depicted in FIG. 1, from Design 1, 

comprehensive, integrated computer-based system and 20 Design 2, and so on to final Design n) as changes are 

method for undertaking an engineering design and devel- recommended and implemented. 

opmenl effort in a virtual coUaborative environment, iden- g^^^ ^ ^^^^ disciplines may be involved, it can 

tifymg quahfied fabncators for manufacturmg a part design appreciated that the process can be lengthy and cosdy, 

basedon fabricator capabmty information stored i^^^ implements changes based on its analysis, 

registry database substantially maintamed by the fabncators 25 ^^^^ j^^y ^^^^ ^ ^^^^ analysis as a result. For 

themselves, and conductmg a virtual bidding process example, when a production engineer recommends (based 

whereby electronic repre^ntations of three dimensional ^ manufacturibility considerations) that paper 

model and specification data arc provided by a central capacitors be employed instead of ceramic capacitors, the 

server. The central server further supports the biddmg pro- reHabiUty engineer will need to reevaluate the design. When 

cess by providing quasi-real time audio, video and graphics. 30 ^ ^^^^ specialist recommends that improved hydro- 

and the contracts negoUation and formahzation steps. ^^^^^ be used or an RF specialist recommends that an 

BACKGROUND OF TOE INVENTION ^'^^ '^^i^^.,^ the mechanical engneer wiU 

need to determine if packaging umits are exceeded and the 

The conventional approach to an engineering design and accounting specialists will need to determine if ^'design to 

development effort tends to be costly and cumbersome. cost** parameters are exceeded. 

Typically, a design and development effort begins with an Application of the "concurrent engineering" principle can 

initial idea or concept for a new product, for example, an improve the process somewhat by assembling the various 

improved sonobuoy for receiving and transmitting to a specialists at the earliest possible time. Thus, manufacturing 

surveiling aircraft acoustic data from the ocean. ^ specialists are consulted fix)m the beginning, rather than 

From this initial idea, an initial design comprising draw- simply at the end. 

ings and written specifications is created. The drawings may Nevertheless, the sonobuoy example and FIG. 1 ilhistrate 

be paper drawings or "blueprints*'or may be three dimen- how a complex engineering effort involving multiple disci- 

sional drawings created using Computer Aided Design plines can be a lengthy and costly process as designs are 

(CAD) software. The initial design will usually include considered and discarded, new designs are evaluated and so 

certain specifications, such as product specifications forth. When the various specialists are in different geo- 

(dc fining performance of the item), system specifications graphical locations ("physical boundaries"), at different 

(defining performance of a system including the item) and business entities ("business boundaries"), or employ differ- 

interface design specifications (defining electronic or physi- ent software standards ("format boundaries'*), the problem is 

cal interfaces between the item and other system only compounded. The disparate locations, business cultures 

components). In the case of a sonobuoy, these documents and format standards can be significant impediments. This 

will include a product ^edfication detailing the perfor- can be referred to as the "boundaries problem." Put simply, 

manoe criteria and "form, fit and fimction" of the sonobuoy; having specialists of differing disciplines (with often con- 

a system specification detailing the performance of the flicting priorities) attempt to resolve design issues when 

system including the sonobuoy and aircraft avionics; and an operating from different locatK>ns, or from business entities 

interface design ^edfication defining the electronic inter- with differing business practices and cultures, or when using 

face between the sonobuoy and the airwaft receiver and different software formats (e.g., three dimensional model 

specialized acoustical processors. standards) creates significant costs and obstacles. Tliis is a 

These specifications will include various design criteria or significant drawback, 

performance parameters for the new sonobuoy, such as so Once an acceptable design is arrived at (e.g.. Design n, 

reliability requirements, mean time between failure, radio FIG. 1), the developing concern typically wishes to produce 

frequency (RF) tr a n smissi on power and range, acoustic gain the design in quantity. In today's decentralized economy, 

and performance (e.g., gain in decibels and three dimen- where most "start-up" or even moderately-sized engineering 

sional beam patterns) and so on. enterprises do not have their own produaion facilities, this 

As depicted in ¥IG. 1, this initial idea or concept is 6S typically requires "outsourcing" of the production. In some 
translated into an initial design, "Design 1." A series of respects, the process of locating qualified, performance- 
teams, comprising one or more members, are assembled to proven fabricators can be as daunting as the engineering 
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development effort. The engineeriiig concern may not have which is accessible by authorized team members through a 

established relationships with many — or any — graphical user interface that is substantially platform inde- 

manufacturers. Of the few potential candidates that may be pendent to reduce or eliminate the necessity for specialized 

identified through "won) of mouth" or a oosdy search, it can hardware and software. 

be costly to evaluate whether such candidates meet mini- 5 U is another object of the present invention for a central 

mum requirements. Numerous meetings may be required. server to support a secure multimedia communications capa- 

Even then, it may be difGcult to ascertain the quality of past bility to include audio, video and graphics, so that partid- 

performance and the prospects for the proposed perfor- pants in an engineering effort can communicate and col- 

manoe. The engineering concern will have to sustain the laborate in the virtual engineering environment to discuss a 

cost, and risk, of divulging proprietary design and specifi- 10 design. 

cation data. Because format standards may differ, the costs ^ another object of the present invention to provide a 

and risks of (sometunes imperfect) file conversions may be ^^^^^^ ^^^j, ^ repository of fabricator capabiUty data 

required. These are significant drawbacks. ^hich can be searched by a prime contractor to locate 

Even if several acceptable fabricators are located, they qualified fabricators based on general criteria as well as 

may represent but a fraction of the otherwise qualified pool i5 design-specific criteria. 

of fabricators. This lessens competition and ultimately, can ^ another object of the present invention to provide a 

lead to increased costs and decreased performance. These central server whereby said fabricator capability data .is . 

are significant disadvantages to the engineering concern. substantially maintained by the fabricators so as to inceo- 

Wiih respect to start-up or not-well-known fabricators, this ^^^^ participate in the so-called manufacturer's 

is a significant drawback that prevents them from penctrat- 20 j^,^^ because it provides them a capabiUty management 

ing new markets and inhibits their growth. system. 

Once a pool (or even a single) of qualified fabricators is ^ another object of the present invention to provide 

identified, die process of negotiating an agreement on per- 5^.^, ^ searchable manufacturer's registry further supporting 

formance must occur. This may require numerous the collection of quality assurance data based on fabricator 

phonecalls, teleconference calls, and face-to-facc meetings. " performance, the quality assurance data being provided to 

Three dimensional models and ^ecification documents may fabricator and to future prime contractors considering 

have to be divulged so that the fabricator can develop a bid. febricator 

Despite rigorous concurrent engineering it is common that ^ ^ ^^^j^^; ^^^^ invention to provide an 

mmor and not-so-minorredesigns may be required due to electronic marketplace and bidding system whereby a prime 

producibiMy concerns. This wil require an addiUond engi- contractor can solicit proposals or bids in a virtual environ- 

neermg effort between the supplier and the proposed fabn- ^^^^ including the provision of specification and three- 

cator to discuss and deade on en^eerag c^^^ amve dimensional model data to prospective fabricators for coo- 

at a mutually acceptable, and pioducible^ign that meets ^ideration in developing their proposals, 

and performance^d cost reqmi^ments. TTie time and effort ^ ^^^^^^ .^^^^.^^ ^^^^ 

entailed arc sigtuficant drawbacks. . i. f.i ut. • \_ * 

such an electronic marketplace whereby a prime contractor 

Engmeermg issues aside, the negotiaUon process can be prospective fabricators can discuss design and cond-ac- 

lenglhy and costly. Documents, which may be proprietary, ^ ^ environment using quasi- real-time 

are sent to the biddmg fabncator. The bidding febncator ^^j^^ ^^deo and graphics, including the three-dimensional 

must evaluate them, engage in discussions with the prime ^ representing the part or product. 

^^^^^'.I'fl^^^^^^ To achieve these and other objects of the present 

a"bid Thisbidtypicdlymcludcstenns rcl^^ invention, and in accordance with the purpose of die 

cost and performance^Upon receipt of the bid^ additional ^^^^^^^^^ ^ embodied and as broadly described, an 

discusaons between the parties may be required to address embodiment of the present invention comprises an apparatus 

engineermg and/or contractual issues. Typically conducted ^^^^ ^ network-based interactive system that 

using a combmation of the phone, teleconference and posta ^^^^^j ^ engineering effort the devel- 

service (or the like), these disunions mipose additional ^ ^^^^ evaluation of an engineering design, the iden- 

costs and tmiem getting a product to market. Tins is a tification of potentially qualified fabricators, and the bidding 

sigmncant drawback. negotiation process to create an agreement for a quali- 

Other problems and drawbacks also exist. fabricator to manufacture a design in quantity. 

SUMMARY OF THE INVENTION Accordingly, what is disclosed is a networic-based system 

interfacing multiple user systems whidi interface through a 

For these and like reasons, what is desired is a network- central server to undertake the design development effort. A 

based, interactive system capable of receiving specification baseline design is created and maintained in a neutral or 

and other information so that an engineering design for a 55 common format by the central server. A governing entity or 

product, represented by an electronic three-dimensional prime contractor assigns access or authorization data so that 

model, can be designed, developed and evaluated in a parts or the entirety of the three dimensional model and/or 

collaborative, virtual environment substantiaUy obviating specification data is accessible by other team members in 

geographic, business and format boundaries. order to perform various analysis and simulations. An inte- 

Accordingly, it is one object of the present invention to 60 grated product data management (PDM) capabihty manages 

overcome one or more of the aforementioned and other access to controlled data and maintains a record of the 

limitationsof existing systems and methods for uindertaking various manifestations of the design. A current baseline 

an engineering development effort design is maintained so that engineering analysis and simu- 

It is another object of the present invention to provide lation team members perform their analysis on the correct 

such a network-based system whereby a central server 65 design. The system supports quasi- real-time interactive 

maintains engineering data, such as design documents and audio, video and graphics so that team members can discuss 

three dimensional model data, in a common, neutral format, design issues in the virtual environment without having to 
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cross geographic or format boundaries. The above-described pan, zoom and "fly tbroughs/* The stored part design model 

capabilities are provided in a substantially platform inde- data may include links to associated specifications, stan- 

pendent manner using a graphical user interface (GUI) dards and other design specific documents so that the 

supported by standard software, such as a "browser," which bidding fabricator has a full representation of what it is 

may further include machine independent applications, such 5 bidding on. As with the NICECAD and GMR aspects of the 

as Java Applets™, or, for certain required tools, a semi- integrated system, the ETC provides "data neutrality" so that 

machine-dependent application, to reduce the processing format boundaries do not become impediments for cither the 

burden on user stations and the need for specialized client- soliciting prime contractor/designer or the bidding fabrica- 

side software. In an alternative embodiment of the invention, tor. 

a so-called "custom browser'* may be provided to user 10 general, the above capabilities are provided in a 
stations so that the interface with the central server system networked, virtual environment that reduces transaction 
is tailored to the present application. In yet another costs and meets engineering challenges as it tnmscends 
embodiment, certain gr^hics-intensive applications may be geographic, business and format boundaries. One or more 
provided by the central server as client-side applications to central servers maintain the part design model in neutral 
be compiled and executed, such as applications coded in 15 format, such as AP 214 STEP format, well known to those 
Open GL""* by Silicon Graphics''''. The so-called common of skill in the art. Substantially platform user independent 
denominator in these embodiments is the goal of retaining graphical interfaces, such as browser pages, and server- 
the most calculation intensive tasks on the server side of the * client interactive applications,- such as Java Applets'™ make 
overall system so as to reduce the need for specialized the system substantially user-system independent In some 
software and hardware capabilities at the user systems. 20 instances^ instead of using Java'™ mini-applications or the 
Additionally, by receiving, converting, and maintaining part like to run on a browser's so-called 'Sirtual machine," 
design models in a common, neutral format, the central certain graphics-intensive or computation-intensive applica- 
server system provides the important benefit of "data neu- tions may be compiled and executed at the user systems as 
trality" for the participants in a concurrent engineering semi- machine-dependent applications amenable to opera- 
development project. In short, formal boundaries are obvi- 25 tions using a computer system with a standard operating 
ated. This is an important benefit, especially for small system. Whether specialized applications are supported by 
enterprises, which might otherwise be eliminated firom par- miniapplications (e.g., such as those coded in Java™) pro- 
ticipation in a project because their software resource do not vided through a browser or by server interface with a 
support a format required by a prime contractor. semi-machine-dependent application at a user station (e.g., 

A second aspect of the system provides a database of 30 a server-provided application coded in Open GL™ readily 

fabricators, a so-called "Global Manufacturer's Registry," executed on a Unix™ — or Windows'^" — based system), the 

which can be searched by a designer or prime contractor to goal is a substantial user platform independent network 

identify qualified fabricators. The database contains various interface with the server system. Security is provided 

information describing the fabricators, such as location. through encryption and multiple firewalls at the server(s) so 

experience, machinery and process capabilities, 35 as to protect proprietary and sensitive data, 

certifications, quality assuranceAnspection standards, and so The accompanying drawings are included to provide a 

forth. Fabricators are incentivized to enroll in the registry further understanding of the invention and are incorporated 

because it provides an incidental benefit as a capability in and constitute part of this specification, illustrate several 

management system they can use to manage and track their embodiments of the invention and, together with the 

resources and capabilities. A prime contractor with a part 40 description, serve to explain the principles of the invention, 

design model representing a product can conduct a search to It will become apparent from the drawings and detailed 

identify qualified fabricators based on design-specific and description that other objects, advantages and benefits of the 

general criteria. The system includes produdbility logic to invention also exist. At the outset, it should be observed that 

analyze an uploaded part design in order to help identify the several primary features of the system are depicted as 

qualified fabricators. Jbc system allows prime contractors to 45 residing on several servers. This is, of course, only for 

provide feedback on performance which can be factored into exemplary and illustrative purposes. The features of col- 

a quality assurance capability provided by the system. As laborative engineering, global manufacturer's registry, and 

with the NICECAD aspect of the integrated system, the electronic bidding, can be provided via one or many servers, 

GMR aspect provides data neutrality for users by supporting which may be co-located or which may reside at different 

the upload and conversion of part design models firom so locations connected through a network. Likewise, the data 

various format types into a standard neutral format. stored by the system could be stored at a single location or 

Therefore, a designer is not precluded firom using the GMR amongst multiple locations in a so-called hybrid relational 

system based on the fact that it uses a particular part design object oriented database architecture. In general, the 

model format. so-called first aspcd of the fully integrated embodiment of 

According to a third aspect of the system, an electronic 55 the invention, the collaborative engineering feature, is 

bidding system is provided by an Electronic Trading Com- described as the Network Integrated Concurrent Engtneer- 

munity (ETC) to allow virtual discussions and negotiations ing With Computer Aided Design or NICECAD. The second 

to take place over the networked system once a pool of Aspect of the invention, the global manufacturer's registry 

qualified fabricators is identified. A request for quote (RFQ) feattire, is described as the Gtobal Manufacturer's Registry 

or request for proposal (RFP) with design data is submitted 60 (GMR) or the Interactive System for Engineering Design 

to the system so that fabricators can submit proposals. The and Manufacuire (EDM). The so-called third aspect of the 

virtual computer aided design (CAD) capability allows invention, the electronic bidding capability feamre, is 

quasi- real-lime discussions, including audio, video and described as the Electronic Trading Community or ETC. 

graphics. The graphics capability allows a prime contractor Additional features and advantages of the invention will 

and prospective fabricator to view the three-dimensional 65 be set forth in the description that follows, and in part will 

part design, including the execution of various be apparent from the description, or may be learned by 

manipulations, such as virtual rotations and translations, practice of the invention. The objectives and other advan- 
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tages of the invention will be realized and attained by the FIGS. 18A & B depict a flowchart illustrating a method, 

system and methods, particularly pointed out in the written according to an embodiment of the present invention, for a 

description and claims hereof as well as the appended team member to perform engineering analysis and simula- 

drawing^ tion on a part design model. 

BRIEF DESCRIPTION OF THE DRAWINGS ^ nCS. 19A & B depict a flowchart iUustrating a method. 

The purpose and advantages of the present invention will according to an embodiment of the present invention, for 

be apparent to those of skill in the art from the foUowing quasi-real lime interaction among users on the NICECAD 

detailed description in conjunction with the appended draw- system. 

ings in which like reference characters are used to indicate FIG. 20 is an overview diagram of an interactive EDM 

like elements, and in which: system according to an embodiment of the invention, includ- 

FIG. 1 is an diagram iUustratiog the concurrent engineer- ing the network interface, GMR server system, GMR 

ing principle, the various teams which may be involved, and database, fabricator user systems and designer user systems, 

the chronology of a typical concurrent engineering devel- piQ 21 is a block diagram, according to an embodiment 

opment project. of the present invention, illustrating a GMR server system in 

FIG. 2 is a biodc diagram illustrating an embodiment of greater detail, including the various processing modules and 

a NICECAD system according to the present invention applications that it may comprise. 

including a network, NICECAD server system,. database, p,Q 22 is a block diagram, according to an embodiment- 
prime contractor user systems and suppUer user systems. present invention, illustrating the GMR database in 
FIG. 3 is a block diagram, according to an embodiment of ^ greater detail, including the stored fabricator data, account 
the present invention, illustrating a database including stored ^^Aa joid other data. 

contracts and agreements data, account data, PDM data, hg. 23 is a flowchart illustrating a method, according to 

clectiomc commerce data, materials data and other data. embodiment of the present invention, for a designer 

FIG. 4 IS a block diagram, accordmg to an embodiment of s^^rch session using an interactive EDM system, 

the present invention, illustrating stored contracts and agree- r-,r- -^a - a *uj _j- 

.j.r-i*L ^FIG. 24isa flowchart illustratmg a method, according to 

ments data or a database. . . ^ ♦ ^« r j • * 

... ^ an embodiment of the present invention, for a designer to 

FIG. 5 IS a block diaoram, accordmg to an embodiment of ^ rrr»x* 

• . ^ , ^ , , retrieve reports using an mteractive EDM system, 

the present mvention, illustrating account data of a database. ^_ , « T .« . . « 

J.^ ^ . , . , J- . u J* ♦ * FIG. 25 IS a flowchart illustratmg a method, according to 

FIG. 6 IS a block diagram, according to an embodiment of ^ c ^t. ^ • *- * ru-* 

, . 2, . , . J an embodiment of the present mvention, for a fabricator 
the present mvenuon, illustrating electromc commerce data 30 ^/"'^"^^"^ ui. juwwu ijiv*.miuu, xui a wuh^uji 

of a database session usmg an mteractive EDM system. 

FIG. 7 is a block diagram, according lo an embodiment of ^ 2? ^ a fimctional diagram of the Electronic Trading 

the present invention, iUustrating materials data of a data- Commumtyof themvenUon,includmgtheGMRuser,GMR 

provider, and manufacturing vendors. 

nG.8isablockdiagram,accordingtoanembodimentof 35 FIG- 27 illustrates how a maniifaauring vendor can 

the present invention, iUustrating PDM data of a database in ^^^^^^e a part design model hosted on a GMR graphics 
greater detail. 

FIG. 9 is a block diagram, according to an embodiment of ^^G. 28 illustrates how a prime contractor and manufac- 

the present invention, iUustrating a NICECAD server turing vendor can engage in a communications session using 
system, inchiding its processing modules. « GMR graphics server, including the substantiaUy simul- 

FIG. 10 is a block diagram, according to an embodiment ^^^^y manipulation of the part design model, 

of the present invention, iUustrating a system administrative DETAILED DESCRIPTION OF THE 

processing module of a NICECAD server system. INVENTION 

FIG. 11 is a block diagram, according to an embodiment ...» 
of the present invenUon, iUustrating a PDM piocessing « . As discussed m the Suinmaiy of the Invention^ present 

module of a NICECAD server system. invenUon is directed to providing a netwtrfoid. virtual. 

........ ... ... . collaborative environmeat for three aaiccts of an cngmeer- 

FIG. 12 IS a block diagram according to an embodiment development: (1) the design ai^devclopmentThasc 

^ 1 ^T^^J^nT^""' lUustratmg a CAD processmg ^ NICECAD ^Networic Integrated Con- 
module of a ^«CECAD server system. Engineering Computer Aided Design); (2) the iden- 

FIG. 13 IS a block diagram, according to an embodmient ^^^^^^ evaluation of qualified fabricators or manu- 

of the present mvention, iUustrating a mid^^ facturers for a design (referred to as the Global 

mcations processmg module of a NICECAD server system. Manufacturer's Registry or GMR system or the Interactive 

FIG. 14 is a block diagram, according to an embodiment System for Engineering Design and Manufacture (EDM), 
of the present invention, flbslrating an electronic commu- 55 ^^d (3) the soUcitation and evaluation of requests for pro- 

nications processing module of a NICECAD server system ^Q^sils or quotes &om quaUficd bidders (referred to as the 

in greater detail. Oectronic Trading Community or ETC). 

FIG. 15 is a blodc diagram, according to an embodiment The First Aspea of the Invention: System and Methods for 

of the present invention, aiustrating an engineering analysis Undertaking an Engineering Design and Development 

and simulation processing module of a NICECAD server Effort in a Virtual and CoUaborative Environment 

system in greater detaU. lo gpneral, the NICECAD server system provides Product 

FIGS. 16A & B depict a flowchart iUustrating a method. Data Management (PDM), CAD functionality, engineering 

according to an embodiment of the present invention, to analysis and simulation (EAS), multimedia communications 

carry out a concurrent engineering project. functionality, electronic commerce capability and front-end 

FIG. 17 is a flowchart illustrating a method, according to 65 network interface and system administration support, 

an embodiment of the present invention, for a design team FIG. 2 depicts an overview of an embodiment of a 

member to create an initial design. NICECAD system 100 according to the present invention. 
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which provides for ooQcurrent engjoeering in a "virtual/* loadable file through a standard browser. As those of skill in 

collaborative eovironmeDt This environment obviates engi- the art may appreciate, prime contractor user systems 220 

neering data format (e.g., CAD geometry), business and may comprise fumie variations of such systems that permit 

other boundaries that presently impede conventional the interaction over a network with a server system, 

approaches to concurrent engineering. Significantly, the s In one embodiment, prime contractor user system 220 

virtual environment provides data neutrality by maintaining comprises a personal computer or workstation running a 

part design models in a common, neutral format, and pro- standard operating system such as V^ndows NT, and using 

viding utilities so that users' specialized part design model a standard browser such as Microsoft Internet Explorer™ 

software formats do not present barriers to participation in a 5.0 cqsable of interpreting HTML 4.0, XML, VRML, and 

collaborative engineoing effort. lO running Java™ applets or like "miniapplications." In 

NICECAD system 100 incorporates product data man- another embodiment, prime contractor user system 220 

agement (PDM), computer aided design (CAD), engineering comprises a personal computer running such a standard 

analysis and simulation (EAS), multimedia communications operating system and using such a standard browser in 

and electronic commerce (EQ so that the entire project, conjunction with client-side applications which, while being 

including its engineering ainl business components, may be IS semi- machine-dependent in the sense they are not executed 

carried out in a virtual, collaborative and secure environ- using a browser's so-called "virtual machine," are otherwise 

ment. compiled and executed using a standard operating system. 

FIG, 2 depicts an embodiment of a NICECADsystein 100 V^plicatibris* coded in" Open GL*™ by Silicon Graphics, a 

according to the present invention, comprising one or more language for graphics applications weU known to those of 

prime contractor user systems 220; one or more supplier 20 skill in the art, and readily supported by Unix™ — and 

user systems 230; one or more databases 210; one or more Windows™ — based systems, would be just one example of 

NICECAD server systems 200; network 260; one or more such a semi- machine-dependent application running on a 

backup data storage devices 250; and one or more backup prime contractor user system 220. In yet another 

server hardware and software devices 240. embodiment, a server-supplied so-called custom browser 

Network 260 may comprise any network that allows 25 application is provided which is specially-adapted for inter- 
communication amongst the components, and may encom- facing with NICECAD server syst6m(s) 200 and any client 
pass existing or future network technologies, such as the side semi- machine-dependent applications (or, 
existing "Internet," "World W\6c Web," Wide Area Network alternatively, Java™ -type or Java™-like miniapplications) it 
(WAN), Local Area Network (LAN), "Internet Protocol- provides. Such semi- machine-dependent applications may 
Next Generation" (sometimes referred to as the coming 30 be server-provided, for example, as downloadable files 
**Supemet"), and any variation of packet switched networks through a standard or custom browser. In each manifestation 
(or other supporting data packing technologies) for permit- of the invention, the overriding goal is to preserve a sub- 
ting communication amongst user systems and servers. stantially platform independent network interface between 
Regarding the Internet and like shared networks, high band- user systems and the server system (e.g., NICECAD server 
width systems have been developed and are becoming 35 system 200). 

increasingly accessible. For example, the Abilene Network Likewise, supplier user systems 230 may comprise any 
developed by University Corporation for Advanced Internet system that may interact with NICECAD server system 200 
Development (UCAID) and the so-called Intemet2 project over network 260. Like prime contractor user systems 230, 
are two examples of such high-capacity systems. The very supplier user systems 230 may comprise any computer 
high performance Backbone Network Service (vBNS) pro- 40 systems, including any of the systems listed above. In one 
vided by MCI Corporation and used by the National Science embodiment, supplier user system 230 comprises a personal 
Foundation and others is another example of such a high- computer or workstation running a standard operating sys- 
capacity system. tern such as Windows NT™, and using a standard browser 
Prime contractor user systems 220 may comprise any such as Microsoft Explorer™ 5.0. As with prime contractor 
system capable of interfacing with network 260. Prime 45 user systems 220, supplier user systems 230 may comprise 
contractor user systons 220 may comprise "standard" com- a personal computer using a server-provided custom 
puter systems that do not require specialized hardware or browser adapted for the present application. As with corn- 
software to use NICECAD system 100. Prime contractor puter systems used by prime contractors, supplier user 
user systems 220 may comprise personal computers, systems 230 may comprise a personal computer running 
microcomputers, minicomputers, portable electronic 50 semi- machine-dependent applications to be compiled and 
devices, a computer network, or any other system operable executed using a standard operating system, 
to interface with netwodc 260 to send and receive data. Backup data storage 250 comprises a system for backing 
Prime contractor user systems 220 may comprise computers up the data stored by the NICECAD system 100. Backup 
running standard operating systems and supporting data storage 250 may comprise several backup technologies 
"browser^ tedmobgies for accessiiig and displaying data 5S for redundancy. Backup data storage 250 may include tape 
over a common network, such as personal computers with media, CD-ROM, zip drives, optical disks or any other 
Windows NT™ and Microsoft Internet Explorer™ 5.0 or reliable means for backing up the data maintained by 
Netscape Communicator™ 4.06, an Apple Macintosh™ NICECAD server system 200. Generally, backup data stor- 
running MOSAIC™ web browser software, a Sun SparcS- age 250 may be data that is stored locally v^rith NICECAD 
tation™ running UNIX and Netscape Communicator™, and 60 server system 200 or remotely. Furthermore, NICECAD 
a Silicon Graphics™ UNIX-based woricstation such as the server system 200, databases 210 and backup data storage 
SGI Octane™ running Netscape Communicator™. Prime 250 may comprise part of a distributed database system. In 
contractor user systems 220 may comprise computer sys- one embodiment, backup data storage 250 may- comprise 
tems running a so-called "custom browser" specially- redundant storage onto high capacity tape and recordable 
adapted for the present application. In one embodiment, 65 CD-ROM. 

such a custom browser may be provided by the NICECAD Backup server hardware and software 240 comprises one 

provider (e.g., NICECAD server system 200) as a down- or more backup servers, including server modules, to rcli- 
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ably support NICEG\D server system 200 to miDimize the the various database and specialized processing operations, 
impact of "crashes" and other events otherwise interfering and a "front end" web server running Windows NT™ and 
with smooth operation. In one embodiment, at least one Microsoft'sTransaction Server™ for network-related opera- 
redundant server may be provided to substitute for tions. 

NICECAD server system 200 should it fail. Generally, 5 As iUustrated in FIG. 2, the architecture of NICECAD 

backup server hardware and software 240 may reside locally ^^^^ ^00 may be distributed. In other words, hardware and 

with NICECAD server system 200 (or a part of NICECAD software for the various NICECAD system functions is not 

server system 200. if it is distributed across several different necessarily resident on one server system at one physical 

servers, to be discussed below), although it may be physi- ^"^^"^ embodmient, as depicted m FIG. 2, 

callyiemote,andmayevenbeaccessiT>irthroughad4rent lo ^^CECAD server system 200 comprises sev^^^^^ 

network address (e.g , at a different URL or web site). ^^^"j^ n ' 771? ^ 

„ ^ . J .1. . _i- -1. * L system 202 for product data management functionahty; 

Datab^^s 210 depict the storage media that may be CAD/EAS server system 204 for computer aided design and 

employed to store data inaintamed by the NICEC/J) sys- engineering analysis and simulation; UMmC server system 

tern. Databases 210 may be one or more physicaUy distinct 2O6 for muhimcdia communications support and electronic 

media, including, but not limited to, hard drives, floppy 15 commerce; and network interface/system administration 208 

drives, CD-ROM, and any other existing or future storage for system administration and network related tasks, 

technologies supporting ready access. Databases 210 may Moreover, these distributed systems may interface through 
* store information for a coricunent engineering developcherit " network 265, which may ' comprise' any of IHc network ' 

project, such as contracts data, engineering data, account technologies discussed in connection with network 260. Of 

data and other project related data (further discussed below 20 course, those of ordinary skill can appreciate that this 

in conjunction with FIGS. 3-8). In one embodiment, data- particular distributed architecmre is exemplary, and the 

bases 210 resides locally with NICECAD server system 200. particular embodiment of FIG. 2 is intended to express the 

In another embodiment, databases 210 is remotely located general principle that all of the NICECAD server system 

from NICECAD server system 200. 200 functionality need not be co-resident. In one 

NICECAD server system 200 comprises a server system 25 embodiment, where the NICECAD system functions are 

supporting the interactive collaborative engineering envi- distributed in this fashion, a single network address, such as 

ronment. NICECAD server system 200 interfaces with an Internet address or URL or web site address, is used by 

prime contractor user systems 220 and supplier user systems the user systems. Access to other parts of the NICECAD 

230 through network 260. NICECAD server system 200 system through network 265 is automated so that the system 

may include the hardware and software to support and 30 appears transparent or "seamless" to the user system, 

interface with prime contractor and supplier user systems on The Database used by the System for Engineering Devel- 

a substantially platform independent basis. This minimizes opment 

user systems* requirements for specialized hardware or FIG. 3 illustrates database(s) 210 maintained by 

software capabilities. This substantial platform indepen- NICECAD system 100, which may comprise contracts and 

dence arises from the fact that NICECAD server system 200 35 agreements data 305; account data 320; materials data 331; 

provides certain specialized applications as either client-side electronic commerce data 394; PDM data 335; and optioo- 

machioe-iodependent applications, such as Java™ applets or ally other data modules 395. 

the like, executable using a standard brov^r (or by a custom Contracts and agreements data 305 may comprise infor- 

browser supporting such applications), and/or as client-side mation stored by NICECAD server system 200 relating to 

semi- machine-dependent applications, such as those coded 40 contracts or agreements among the various actors. This data 

in Open GL™ or like coding tools, to be executed on a may comprise contracts between users and NICECAD sys- 

machine with a standard operating system. Ultimately, sig- tern data module 410 and contracts between prime contrac- 

nificant benefits of the invention derive from the fact that the tors and suppliers data module 415, as depicted in FIG. 4. 

user system interface with NICECAD server system 200 is The former may generally comprise those agreements 

substantially platform independent. 4S regarding the terms of usage of the NICECAD system, such 

Generally, NICECAD server system 200 includes system as fee stmcturc, security, assignment of liability, and so on. 

administration and network-related software modules^ as The latter may contain records of contracts or agreements 

well as the various specialized sofitware modutes for CAD, entered into between prime contractors and siq)pliers or 

EAS, multimedia commimicatioDs and EC. Certain of the between suppliers. In one embodiment, such contracts may 

software modules may be client-side interactive for support- 50 be prepared over the network by tailoring standard contracts 

ing specialized concurrent engineering tasks. For example, and contract terms provided by the NICECAD system, 

NICECAD server system 200 may also include the hardware further discussed in connection with FIG. 6. 

and software for multimedia operations such as audio, video Account data 320 may comprise information stored by the 

and graphics, that may be transmitted over the network for NICECAD system pertaining to use by prime contractors 

presentation to user systems with standard client-side mul- 55 and suppliers. For example, the information may comprise 

timedia support records reflecting all user transactions, including billing 

In one embodiment, NICECAD server system 200 may be information, so that a complete history associated with a 

publicly accessible as a web site, but may provide multiple particular project is available. In one embodiment, every 

levels of security (e.g., multiple '^firewalls*') to ensure that concurrent engineering development project is assigned an 

proprietary project data may be protected. For example, 60 identifier, such as project number or project name, which 

NICECADserversystem200may be accessed only by users may be used to retrieve account records in a relational 

with a user ID and password. In one embodiment, the data database arrangement. In one embodiment, account data 320 

transmitted is compressed and encrypted using encryption at may be logically divided into supplier account data module 

least as reliable as that provided by RSA 1024 bit encryption 525 and prime contractor account data module 530, as 

keys, a technology well known to those of skill in the art. In 65 illustrated in FIG. 5. 

one embodiment, NICECAD server system 200 may com- Electronic commerece (EC) data 394 may comprise data 

prise a ''back end** processirig senwr running UNIX™ for related to electronic commerece transactions carried out 
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using NICECAD system 100. The NICECAD server system Subsequently, a fabricator team analyzing the 3D solid 

200 may be configured to aUow business transactions per- model (e.g., when analyzing the design to prepare a bid) may 

taining to the engineering develofHiient effort to be carried ascertain that a particular material is to be used for a 

out in the virtual environment, such as negotiations, particular entity, and then may learn about applications and 

contracting, and funds tranfer. EC data 394 may be used to 5 properties of that material by accessing materials data 331. 

stoic records of such transactions, and may comprise stored PDM data 335 may contain the data stored for individual 

standard contracts data module 696; stored standard terms concurrent engineering development projects. Broadly 

and conditions data module 697; stored electronic business speaking, the concept of PDM is to create an information 

documents data module 698; and stored EC digital signature infrastructure for the entire history of an ei^ineering effort, 

data module 699, as illustrated in FIG. 6. lO including technical data (such as the design evolution and 

Stored standard contracts data module 696 may comprise analysis/simulation results), as well as business or manage- 
a series of contract ''templates" for prime contractors and ment data (such as contracts and budget/schedule 
suppliers to use as a starting point for creating an agreement. information). Accordingly, PDM data 335 may include 
For example, in one embodiment there is a standard form modules with project specific data (such as part design 
agreement for a fabricator to produce a quantity of proto- 15 models for particular projects) and non- project specific data 
types of a design within some time-frame. There may be (such as reference modules to facilitate creating part design 
another standard form contract for an HAS team to perform models). PDM data 335 may comprise the following mod- 
some specified analysis on a design. 'Stored standard terms ' ules: stored product data management systeni' "electronic " 
and conditions data module 697 may comprise various terms document data module 840; stored product data and elec- 
and conditions to be used in preparing an agreement includ- 20 tronic document distribution control module 855; stored 
ing such things as liquidated damages, arbitration clauses, design and analysis access permission data module 860; 
procedures for engineering changes, and the like. Those of stored baseline part design model data module 865; and 
ordinary skill can appreciate that module 696 may be used stored working copy part design model data module 892; 
with or without module 697, and that said modules could standard and custom parts Library data module 875; stored 
easily be combined. 25 engineering analysis and simulation results data module 

Stored electronic business documents data module 698 885; manufacturing staodards and specifications data mod- 
may comprise documents or records related to all EC ule 850; stored standard attibutes and attribute values data 
transactions. For example, when a prime contractor transfers module 845; stored 880; stored quasi-real time multimedia 
funds to a suppher, a record may be stored in this module. communications sessions data module 890; and other PDM 
If standard form contract or standard terms and conditions 30 data modules 891, as illustrated in FIG. 8. 
data is accessed, a record may be stored. If a contract is Stored product data management system electronic docu- 
actually entered into using the NICECAD system 100, a ment data module 840 may comprise non-graphic project 
record may be stored. In general, this module ensures that documents, such as project specifications, change 
NICECAD system 100 provides an electronic **paper trail" documents, revision history documents, and budget and 
that provides a history of the business transactions carried 35 schedule documents. Change documents refers to any docu- 
out using the NICECAD system. ments that may be prepared to implement a design change. 

Stored EC digital signature data module 699 may com- For example, in Department of Defense applications, such 

prise data of a ''digital signature" required to formalize documents are sometimes referred to as '^engineering change 

agreements between users. Analogous to the usual process, proposals" or ''engineering change orders." Revision history 

an agreement may be considered finalized when the parties 40 documents refers to any documents that list or provide a 

provide their digital signature signifying their assent to the history of design changes. 

terms. Stored product data and electronic document distribution 
Materials data 331 may contain information relating to control data module 855 may comprise a module for main- 
materials that may be used to fabricate a part design model taining "check-in/check-out** records that dociunent when 
and may be used as a reference tool for designers, analysts 45 team members access certain documents in NICECAD 
and fabricators. Materials data 331 may contain property system 100. In one embodiment, every time a user accesses 
data as well as applications data. For example, materials data or "checks out" a specification or part design model, a 
331 may have an entry for a titanium alloy identifying '^time-stamp" and team member identifier is stored in this 
properties such as elastic modulus, tensile strength, module (e.g., see FIG. 11, module 1104). This serves con- 
hardness, madiinability, ductility or other properties. Mate- 50 figuration management by providing an electronic "paper 
rials data 331 might contain applications data for the tita- trail." 

nium alloy, such as its limitations when used in a high Check-in/chedc-out controls generaUy refers to the pro- 
oxygen environment. As illustrated in FIG. 7, materials data cedures employed by the NICECAD system to control 
331 may be logically subdivided into homogeneous mate- access to proprietary part design model and specification 
rials data module 732 for homogeneous materials; hetero- 55 data. As will be discu^ed further below, the prime contrac- 
geneous materials data module 733 for heterogeneous mate- tor may assign access permissions to part or all of the part 
rials; and other materials data module 734 for materials not design model, project specification, and the EAS processing 
easily classified. For example, properties and/or applications modules. This ensures that the prime contractor has control 
data for materials like metals, plastics, ceramics and the like, over which teams access which data, and which teams run 
may be stored in module 732. Properties and/or applications 60 which analysis. Whenever an authorized team member 
data for materials like carbon fiber-epoxy or Kevlar™ accesses the part design model or specification, the team 
composites may be stored in module 733. member is said to have "checked out" that item. Once the 
Materials data 331 may be used as a reference source or team member completes the task, he/she may have to "dieck 
it may be used in conjunction with the CAD tools to create in" the item by informing the NICECAD system that the task 
a design. For example, materials data 331 may be used by a 65 is complete. By updating the check-in/check-out data in 
design team to assign or associate certain materials with stored product data and electronic document distribution 
entities of a part design model (such as a 3D soHd model). control data module 855, the NICECAD system provides 



11/19/2003, EAST Version: 1.4.1 



us 6.295^13 Bl 

15 16 

coofiguratioD oontrol by maintaining a history of which copy veisioo numbers. la another embodiment, the working 

teams have accessed which part design models and docu- copy veision numbers are maintained so that there is a 

ments. complete history of all working copies of the part design 

It is important to appreciate that check-in/check-out model in the NICECAD system, 

records may stiU be maintained even if an approval authority 5 Standard and custom parts library data module 875 may 

does not limit access to the part design model, specifications, comprise a library of "pre-buiir standard and custom parts 

or EAS processing modules accessed by designers to mclude m larger part 

Storeddesignandanalysisaccesspermissiondatamodule Availability of such data may expe^te the 

860 may comprise data assigned by the prime contractor ^^'E creaUon and modificauon process (e.g., see FIG. 9, 

determiningwhichteams(ort^member5)mayaccessthe lO ^"^^^ ?}' parts may mclude such common 

*j ji J _ * jcAo • J 1 Items as fasteners, gears, bearmg sets and the like. Custom 

partdesjimodeUdocumentsand^processingm^^^^^ parts may include pirts previously built by prime contractois 

TTie module may also comprise date determining which jj^^ ^^^^ ^ 

teams may access oertem project documents, such as s^^^ example, a sonobuoy manufacturer may save a series of 

fications. A part design model generally comprises a sencs custom parts for various configurations of sound-detecting 

of geometric and topological entities. Teams, sudi as EAS 15 underwater hydrophones. 

teams, may need access to all or part of a part design model Stored engineering analysis and simulation results data 

in order to carry out the analysis for their specific discipline. module 885 may comprise data stored by the NICECAD 

They niay heed to access specifications or other'documents system reflecting the results of engineering analysis pcr- 

to perform their tasks. Likewise, those teams may need to formed by EAS teams. The EAS analysis may be performed 

access one or more EAS processing modules to carry out the 20 using internal NICECAD processing modules (e.g., see FIG. 

analysis. Stored design and analysis access permission data 9, module 946) or external processing modules. Stored 

module 860 allows an approval authority to assign access engineering analysis and simulation results data module 885 

permissions to limit access to those portions of the part ensures that the virtual NICECAD collaborative engineering 

design module, those specifications (or portions thereof), environment includes a record of analysis performed on a 

and those EAS processing modules as appropriate. This 25 part design model. Those ofordinaryskiU should appreciate 

serves configuration control by limiting access to only those that the term "engineering analysis and simulation" is gen- 

who need it. erally descriptive of studies performed by various teams 

Stored baseline part design model data module 865 may considering a design. The term is not meant to suggest that 

contain the current approved version of the design referred analysis and simulation are discrete tasks or disciplines, 

to as the "baseline." Each time a design change is approved 30 Some studies may involve only analysis of a design; some 

by the prime contractor, the baseline part design model may may involve only simulation of the operation or manufacture 

change. A part design model may be created using the of a design; and some studies may require both simulation 

NICECAD CAD capability, and generally comprises a and analysis. 

series of entities (e.g., topological or geometric features) Manufacturing standards and specifications data module 

which may be assigned attributes and attribute values. 35 850 may comprise fabrication standards, inspection stan- 

Attributes include such items as tolerance, surface finish, dards and other standards. For example, to support Depart- 

material, special fabrication instructions, etc. In general, ment of Defense applications, this module may contain 

stored baseline part design model data module 865 may various MIL-STD or MIL-SPEC documents defining such 

contain the part design models, such as 3D solid models, things as manufacturing standards, inspection standards, 

including attributes^ for the projects in NICECAD system 40 reliability, quality assurance, safety, and so on. This module 

100. In one embodiment, this module may contain the entire may be used as a reference source providing users the text 

history of baseline designs, each of which is assigned a of the standards and specifications. This module may be 

version number for tracking purposes (e.g., Design 1.00, used by designers to associate particular standards with 

1.01, 1.02, etc.). Hie latest version number may be the graphical entities of a part design model. In one 

current baseline design. 45 embodiment, a design team member may associate a stan- 

Stored working copy part design model data module 892 dard (e.g., MIL-STD-5556.8) with a particular graphical 

may be used by designers and analysts as a virtual '^scratch entity when creating a part design model. When viewing the 

pad^ for storing part design models. For example, an EAS design using a CAD tool (e.g., see FIG. 9, module 932) a 

team member who checks out the current baseline part fabricator team member may see the standard associated 

design model frc»n module 865 may not be permitted to 50 with a particular entity that may be ''clidced on" to link to 

"dieck in" that part design model. Hiis is because it may be the text of the standard. 

that only the prime contractor can authorize writing a Stored standard attributes and attribute values data mod- 
baseline part design model to module 865. This provides ule 845 may comprise a series of standard attributes and 
configuration oontrol and protects the integrity of the current attribute values for use by a designer in creating a design. As 
baseline part design model. However, the EAS team member 55 previously mentioned, a part design model may comprise a 
may use stored working copy part design model data module series of geometrical and topological entities. Each entity 
892 to store a "working copy" of the part design model. For may be assigned its own attributes, such as surface finish, 
example, if a fabricator team analyzing produdbility deter- material, tolerance, and the like. For some attributes, each 
mines that certain design changes should be effected, a attribute is given a value or category. For example, tolerance 
proposed revised baseline part design model may be stored 60 may be given a tolerance type (e.g., flatness, linear, angular, 
in this module. Project team members may also use this mnout, etc.) and a tolerance range. For surface finish, a 
module to temporarily store working copies of the baseline surface finish value is assigned. Stored standard attributes 
part design model while they are completing their analysis. and attribute values data module 845 may be used in 
This way the team member does not have to go through the connection with a CAD tool (e.g., see FIG, 9, module 932) 
check-out procedures repeatedly while performing the same 65 so that a designer may rapidly create an initial design 
analysis. In one embodiment, the working copies stored in including the assignment of attributes to the part design 
this module by NICECAD server 200 are assigned working model entities. 
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Stored PDM digital sigoature data module 870 may mission of 3D graphics between user stations and 

comprise digital signatures, well known to those of skill in NICECAD server system 200 can be implemented using a 

the art, by the "approving authorit/* for the part design high-level platform independent 3D graphics programming 

model. In conventional collaborative engineering tool such as Java 3D'^ 1.1 API. 

environments, the "approving authority^ (usually the prime 5 As noted previously, in one embodiment user access to the 

contractor) signifies approval of the baseline part design processing modules of NICECAD server system 200 is 

model and associated deification documents by affixing a facilitated using a custom browser specially ad{q>t6d for the 

written signature. In the virtual NICECAD environment, a present application. Additionally, certain client-side appli- 

digital signature may be associated or included to certify cations are better provided as semi- machine-dependent ' 

approval of certain items, such as the approved current lo applications that are compiled and executed using a standard 

baseline part design model, the approved final part design operating system, although not via the "virtual machine** 

model submitted for fabrication, and various supporting provided by a standard browser. For example, certain 

specification documents. This digital signature feature aids graj^ics-intensive applications, such as those for supporting 

configuration control by providing a quick and efEcctive way the invention's virtual CAD and multimedia video/audio/ 

to determine whether a particular electronic file represents is graphics capability, ay be provided as Open GL™-coded 

an "approved" version or is a mere working copy (or applications rather than Java 30*™ -coded applets, 

proposed redesign). In one embodiment, design changes It bears reiteration that NICECAD Server System 200, 
require a 'digital' signature by 'the approving authority,' primarily for design development, and GMR Server System 

whereby a new design must include the proper digital 1000 (discussed below), primarily for locating qualified 

signature (e.g., a key) before it may be stored in stored 20 fabricators, and GMR Graphics Server 2710 (discussed 

baseline part design model data module 865. In other below), primarily for the bidding process, may exist at the 

embodiments, digital signatures may not be required. same location on the same server system. In the preferred 

Stored standard drawing symbols data module 880 may embodiment, the overall system provides a comprehensive 

comprise a series of standard drawing symbols, such as functionality, hosted on a single system, for the entire 

ASME Y14.5 symbols. These symbols may be used by a 25 product development lifecycle, fi-om initial idea by a prime 

designer in creating a part design model using the CAD tool contractor/designer to production in quantity by an out- 

(e.g,, see FIG. 9, module 932). In one embodiment, where sourced fabricator. For illustrative purposes, we describe the 

the CAD tool includes a custom design visualization func- various functional components as residing on separate 

tionality (e.g., see FIG, 12, module 1210, discussed below), servers, although this architecture is not required, and in the 

stored standard drawing symbols data module 880 may be 30 preferred embodiment, the three aspects of the invention are 

automatically accessed by NICECAD server system 200 to integrated into a substantially "seamless" virmal enviroo- 

provide the proper drawing symbols for a two-dimensional ment. 

sectional view of a 3D part design model As illustrated by FIG. 9, NICECAD server system 200 
Stored quasi-real time multimedia communications ses- may comprise system administration processing module 
sions data module 890 may comprise records data of mul- 35 902; PDM processing module 918; CAD processing module 
timedia communications sessions (e.g., see FIG. 9, module 932; multimedia communications processing module 978; 
978) between teams members in a concurrent engineering electronic commerce processing module 988; and engineer- 
development project. For example, if a design team and EAS ing analysis and simulation processing module 946. 
team have a multimedia communications session using the System Administrative E^cessing in the NICECAD System 
NICECAD system to discuss certain design issues, a record 40 System administration processing module 902 generally 
may be stored reflecting the session. In one embodiment, sti^ports system administrative processing and network 
data reflecting the acmal transactions (such as audio, video related processing, and, as depicted in FIG. 10, may further 
and graphics) may be stored for a session. In another comprise user logon authentication processing module 
embodiment, memory resources are preserved by storing 1002; contracts processing module 1004; account data and 
only descriptive information, such as the identity of the 4S other report generation module 1006; security processing 
parties, duration of the session, part design model version module 1008; network interface processing module 1012; 
numbers accessed and the like. data backup and archiving processing module 1013; and 

Other PDM data modules 891 may comprise any other other application modules 1014. 
data modules in PDM data 335. Other data modules 395 may User logon audientication processing module 1002 may 
comprise any other data nxxtules in database 210. 50 comprise a security module for limiting access to the 
The NICECAD Server System NICECAD system. User logon authentication module 10Q2 
FIG. 9 illustrates NICECAD server system 200, which may enable a user to enter a user ID and password to log 
may comprise various software oompooents or modules onto NICECAD system 100. Other security modules may 
supporting processing functions. At the outset, it should be also be provided. In one embodiment, a prime contractor 
noted that in one embodiment, user access to the processing S5 initiates a development project on NICECAD system 100 
modules of FIGS. 9-15 may be via platform independent and accordingly identifies the various teams (and team 
graphical user interfaces (e.g., browser pages) presented to members). This module then gives the various team mem- 
the user's standard or custom browser. In another bers authorization to log onto the system for a given project, 
embodiment, user interface to processing modules may be Contracts processing module 1(M)4 may comprise a mod- 
further enabled by the provision of platform independent 60 ule that ensures that before a prime contractor or supplier 
miniapplications (e.g., Java*^ applets or the like) that may uses NICECAD system 100, contracts specifying the 
be run on user stations. Such applications may reduce or responsibilities of each party regarding data protection, 
eliminate the need for specialized hardware/software at user maintenance and system usage are formalized (e.g., see FIG. 
stations, may provide client/server interactivity, and may be 4, module 410). In one embodiment, contracts processing 
used to reallocate processing burdens between the server 65 module 1004 includes a platform independent client-side 
system and user systems. For example, applications involv- Java™ applet (or like miniapplication) that may be launched 
ing 3D graphics presented at user stations and/or the trans- at user stations to fedlitate the contract execution process. 
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Account data and other report generation module 1006 bility of NICECAD system 100. This module may provide 
may comprise a module that formats and sends reports for the data management and configuration control of non- 
requested by users that, in one embodiment, may be sent as graphic project documents such as project specifications, 
browser pages or links to downloadable files. This module change documents or revision history documents (e.g., see 
may prepare reports of records of transactions on the s FIG. 8, module 840). In one embodiment, PDM electronic 
NICECAD system or billing summaries. (See» e.g., FIG. 5, docimient processing module 1102 comprises a substantially 
module 320). In one embodiment, a prime contractor may COTS (commercial off-the-shelf) software package tailored 
retrieve reports pertaining to all transactions relating to a for NICECAD system 100. 

given project, while suppliers may retrieve reports only Product data and electronic document distribution control 
pertaining to their own activity. 10 module 1104 carries out the check-out/check-in manage- 
Security processing module 1008 may comprise a module ment procedures of the NICECAD system (e.g., see.FIG. 8, 
for providing security for NICECAD system 100. It is module 855). As mentioned previously, the check-in/check- 
important that project data and multimedia communications out procedures ensure the integrity of the part design model 
sessions are secure, so this module may provide multiple ai^ associated specification documents. This module may 
firewalls, encryption, hashing, or other known information IS provide that each time a controlled item, such as a part 
technology security techniques to protect data and commu- design model or a specification document, is accessed from 
nications. In general, project data may be treated as propri- the NICECAD system, a record is stored reflecting that 
etary to the prime contractor, and security processing mod- transaction. In one embodiment, this record may cbmprise'a 
ule 1008 provides the proper safeguards. In one time-stamp and user ID. 

embodiment, security processing module 1008 may com- 20 Baseline part design model management module 1106 

prise a software component using Java™ Cryptography may be a module that provides data management of the 

Extension (JCE) 1.2 and Java™ 2 for encryption and/or baseline part design model. In general, baseline part design 

message authentication. In the preferred embodiment, data is model management module 1106 may be integrated with or 

compressed and also encrypted using technology at least as may cooperate with a CAD processing module (e.g., see 

reliable as that provided by RSA 1024 bit encryption keys. 25 FIG. 9, module 932) so that the latter provides the substan- 

Network interface processing module 1012 may comprise tive CAD capability and the former provides the PDM 
a module for supporting the interface with user systems over fiinctionality. Baseline part design model management mod- 
network 260, or for interface with other parts of NICECAD ule 1106 may be integrated with a data module such as that 
server system 200 via network 265. In one embodiment, of FIG. 8, module 865, to store the baseline part design 
network interface processing module 1012 supports the 30 model. In one embodiment, configuration control is fiir- 
interface with user systems on a substantially platform thered by having the NICECAD server system 200 config- 
independent basis using browser pages or the like. In this ured so that baseline part design model management module 
manner, user interface with NICECAD server system 200 is 1106 permits only one category of user, such as approval 
achieved using more or less standard hardware and software. authority users, to create or make changes to the baseline 
As previously noted, such browser pages may be configured 35 part design model. This module (1106) may cooperate with 
to interface with a so-caUed standard, commercially avail- product data and electronic document distribution control 
able browser (e.g., Netscape™ or Microsoft Explorer™) or module 1104 to enforce the check-in/check-out procedures, 
a custom browser specially adapted to support the graphics- This module (1106) may provide that each version of the 
intensive networked CAD and multimedia communications baseline part design model is given a version number, 
aspects of the present invention. 40 Working copy part design model management module 

Data backup and archiving processing module 1013 may 1108 is similar to baseline part design model management 

comprise a module supporting periodic backing up and module 1106, except that the former manages the data 

archiving of data (e.g., see FIG. 2, module 250). This associated with so-called "working copies" of the part 

module may also support the resort to backup server hard- design model (e.g., see FIG. 8, module 892). This module 

ware andl/or software (e.g., see FIG. 2, module 240) when 45 may provide PDM managemrait when cooperating with a 

there are system crashes or other interruptions in availability CAD processing module that provides substantive CAD 

of the primary server hardware and software (e.g., see FIG. processing to a user relying on a working copy. This module 

2, module 200). may provide that each version of a working copy part design 

Other application modules 1014 may comprise any other model is given a version number, 

application modules nin by NICECAD server system 200 to 50 Attributes and attribute values management module 1110 

support system administration related tasks. may comprise a module that provides PDM management of 

Product Data Management Processing in the NICECAD attributes and attribute values (e.g., see FIG. 8, module 845) 

System inputted by a user. This module may provide that attributes 

PDM processing module 918 provides the processing and attribute values assigned to a part design model be 
associated with the NICECAD system's PDM fimctionality, 55 stored with the part design model (e.g., see FIG. 8, modules 
and, as depicted in FIG. 11, may include PDM electronic 865 and 892) or in a separate location. This module may 
document processing module 1102; product data and elec- cooperate with a CAD processing module (e.g., see FIG. 12, 
tronic document distribution control module 1104; baseline module 932) that permits a user to view the part design 
part design model management module 1106; working copy model and assign attributes and attribute values to selected 
part design model management module 1108; attributes and 60 entities. In one embodiment, this module cooperates with a 
attribute values management module 1110; PDM digital platform independent client-side application (such as a 
signature processing module 1112; engineering analysis and Java™ applet running on a browser) or a semi- machine- 
simulation results management module 1114; design and dependent application that permits the user to view the part 
analysis access permissions management module 1116; and design model and assign attributes and attribute values by 
other PDM processing modules 1118. 65 selecting entities with a mouse or like device. 

PDM electronic document processing module 1102 may PDM digital signature processing module 1112 may cam- 
comprise a module that implements the general PDM capa- prise a module for managing the digital signature data in 
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NICECAD system 100. In one embodiment, this module (e.g., prime contractor user systems 220 or supplier user 
provides the user a platform independent application, such systems 230) interface through standard or server-provided 
as a Java™ applet, that permits the user to append or custom browsers with 3D part design model graphics pre- 
associate a digital signature with a part design model or sentation and manipulation facilitated using server-supplied 
document (such as a project specification). The digital 5 (e.g., by CAD processing module 932) Java*"* applets (or 
signature component (e.g., the key) known to the user is like miniapplications which can be executed on a browser), 
uploaded to the NICECAD system, where PDNf digital In another embodiment, so-called semi- machine-dependent 
signature processing module 1112 ensures that it is properly applications may be provided by CAD processing module 
validated and that appropriate records of the signing are for execution on a user system with a standard operating 
made (e.g., see FIG. 8, module 870). In one embodiment, lO system to support demanding graphics applications. 
PDM digital signature processing module 1112 may com- CAD processing module 932 may be a module for sup- 
prise a software component using Java™ Cryptography porting the CAD processing capability of NICECAD system 
Extension (JCE) 1.2 and Java™ 2 for creating the digital 100 and, as depicted in FIG. 12, may further comprise part 
signatures. design model creation and editing processing module 1202; 

Engineering analysis and simulation results management 15 standard and custom parts library management module 

module 1114 may be a module that manages the EAS results 1204; standard drawing symbols management module 1206; 

for the NICECAD system (e.g., see FIG. 8, module 885). manufacturing standards and ^ecifications management 

This module may cooperate with iiiodules that perform the module 1208; part design model visualization and manipu- 

substantive EAS processing (e.g., see FIG. 15, module 946). lation processing module 1210; CAD utilities conversion/ 

Design and analysis access permissions management 20 plotting module 1214; and other CAD support processing 

module 1116 may comprise a module that provides the modules 1216. 

processing to allow a prime contractor or approval authority Part design model creating and editing processing module 
to assign access permissions to various teams or team 1202 is a module that may provide the capability for a user 
members. This module may provide the processing to deter- to create and modify part design models, such as 3D sohd 
mine whether access is granted or denied when a data 25 models. In one embodiment, this module includes a platform 
request is made. In one embodiment, NICECAD server independent cHent side appHcation, such as a Java™ applet, 
system 200 facilitates the access assignment process by so that the user may rely on standard hardware and software, 
providing a platform independent interactive application, including a standard graphical interface (such as a web 
such as a Java™ applet, that lists varioiis project data (such browser), in order to create and modify part design models, 
as the part design model and project specifications) and EAS 30 In one embodiment, part design model creating and editing 
processing modules, and the various team members. The processing module 1202 comprises a commercially avail- 
prime contractor, through the use of keyboard input, able software product, such as Mechanical Desktop™ from 
"mouse," or similar device, may then assign viewing per- AutoDesk, SolidEdge™ fi-om Uoigraphics, or Quick HDL 
missions for each item, which are then uploaded to the or Auto logic HDL™ from Mentor Graphics Corp., that has 
NICECAD server system 200 (e.g., see FIG. 8, module 860). 35 been customized and implemented for a server-based net- 
Other PDM processing modules 1118 refers to any other worked application. In one embodiment, the provision of 
PDM processing modules for managing the data in a con- graphics (such as 3D graphics) over network 260 is imple- 
current engineering development project. mented using graphics applications known in the art, such as 
Computer Aided Design (CAD) Processing Java 3D™ 1.1 API (Application Programming Interface), 
At the outset, it should be appreciated that CAD process- 40 which can be used for creating and manipulating geometry 
ing module 932 may be used by design and analysis team of 3D graphical objects. As previously noted, another 
members during the design and development phase to embodiment provides that particularly demanding graphics 
create, analyze and modify a part design model represented applications be provided as semi- machine-dependent 
as a three dimensional solid model file or the l^e. CAD applications, such as those coded in Open GL™, provided to 
processing module 932 may also be linked to the second 45 user systems for execution. As before, the overriding goal is 
aq>ect of the overall system (GMR database searching for to maintain a substantially user platform independent net- 
qualified fabricators) insofar it provides a means to create work interface, presenre data neutrality, and focus the pro- 
and/or uptoad models for a part design that will be analyzed ces^ng (computational) burden on the server system rather 
using the producibility logic to be discussed below in than the user systems. 

connection with FIGS. 20-25. Alternatively, the conversion 50 Standard and custom parts library management module 

utility of CAD processing module 932 could be used to 1204 may be a module that coordinates the use of a library 

upload and convert for storage in a neutral format a part of standard and custom parts by a team member creating a 

design model already in existence (i.e., not initially created design (e.g., see FIG. 8, module 875). In one embodiment, 

using the NICECAD collaborative, virtual environment). this module represents a custom feature added to or inte- 

CAD processing module 932 may also be linked to the third 55 grated with a commercially available CAD product, as 

aspect of the overall system (Electronic Trading discussed above. 

Community) insofar it provides a means to create (or upload Standard drawing symbols management module 1206 

and convert a previously created part design model) and may be a module that coordinates the use of a library of 

store a part design model that will be made available to standard drawing symbols by a team member creating a 

fabricators preparing bids for a fabrication effort. 60 design (e.g., see FIG. 8, module 880). In one embodiment. 

As previously discussed, computation- and graphics- this module represents a custom feature added to or inte- 

intensive applications, such as the present inventions CAD grated with a commercially available CAD product, as 

functionality, may be provided according to several possible discussed above. This module may also associate the proper 

embodiments, each of which pursues the goal of a substan- drawing symtx>ls with entities of a part design model that is 

tially independent network interface between user systems 65 depicted as a two-dimensional section after being subjected 

and a central server system. For example, in one to the 'Virmal cutting tool" (discussed further below in 

embodiment, CAD processing module 932 and user systems connection with module 1210). 
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ManufactuiiDg standards and specifications management 
module 1208 may be a module that coordinates the use of a 
library of standards aod specifications by a team member 
creating a design (e.g., see FIG. 8, module 850). In one 
embodiment, this module represents a custom feature added 5 
to or integrated with a oommeicially available CAD product, 
as discussed above. For example, the embodiment of part 
design model creation md editing prooessii^ module 1202 
using a Java™ applet or the like may be linked to manu- 
facturing standards and specifications management module lo 
1208. In this embodiment, a user creating a part design 
model can readily assign standards and specifications to 
graphical entities. In another embodiment, this module per- 
mits a user viewing a design (such as a fabricator evaluating 
a design in order to develop a bid) to link from an attribute 15 
associated with an entity to the imderlying ^ecification or 
standard. 

" Part design model visualization and manipulation pro-'" 
cessing module 1210 may be a module that permits users to 
manipulate (e.g., translate, rotate, etc.), "mark up" and "cut" 20 
a part design model, such as a 3D solid model. This 
capability may be considered a supplement to the basic CAD 
functionality of part design model creation and editing 
processing module 1202. "Mark up" refers to comments or 
marks that may be appended to the part design model, which 25 
may be especially uscfull when engaged in an interactive 
multimedia session (see FIG. 19, below). Part design model 
visuahzation and manipulation processing module 1210 
may permit software "cuts" using a "virtual cutting tool" to 
provide two-dimensional (2D) sections of a 3D part design 30 
model. The 2D sections may be appended with drawing 
symbols from a library of drawing symbols (e.g., see FIG. 
12, module 1206, and FIG. 8, module 880) so that the 
electronic equivalent of standard 2D drawings are generated. 
Part design model visualization and manipulation process- 35 
ing module 1210 also supports functionality to view the 
design according to different perspectives^ including zoom 
and pan functions^ and so-called virtual "fly throughs." "Fly 
throughs'' allow the user to inspect interior regions of a part 
design not readily ascertainable in standard drawing per- 40 
spectives. 

In one embodiment, part design model visualization and 
manipulation processing module 1210 includes a platform 
independent client application, such as a Java"^ applet, that 
is integrated with the NICECAD system's multimedia com- 45 
municatioos feature (e.g., see FIG. 13, module 978) so that 
single or multiple "on line" users may view 2D sectionals, 
fly throughs, and other views of the part design model that 
are generated in a substantially "on the fly^ fashion. In one 
embodiment, part design model visualization and manipu- so 
lation processing module 1210 comprises an application 
coded in Java 3D'"< 1.1 for 3D graphics. In this embodiment, 
the part design model is presented as a Java 3D™-oonverted 
representation of ±e part design model stored in a neutral 
format, such as AP214 STEP format. In another S5 
embodiment, part design model visualization and manipu- 
lation processing module 1210 comprises a server-provided 
semi- machine-dependent application (such as one coded in 
Open GL"^ for execution on user systems with standard 
operating systems. 60 

CAD utilities conversion/plotting module 1214 may be a 
module that provides various CAD utilities, such as file 
format conversion and output plotting. For example, this 
module may permit users to convert part design models 
among various formats, such as AutoCAD™, 65 
ProEngineer™, IGES, STEP, and other CAD file formats 
known to those of skill in the art. This capability may be 
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useful when an EAS team member is performing an "off- 
line" analysis requiring a format different from that normally 
stored in NICECAD system 100. This module may permit a 
user to generate electronic or bard copies of the part design 
model, such as 2D drawings generated using the cutting tool. 
In one embodiment, CAD utilities conversion/plotting mod- 
ule 1214 includes a platform independent Java"^ applet or 
the like to facilitate file conversion or plotting. In the 
preferred embodiment, this platform independent applica- 
tion provides data compression functionality to reduce the 
time required for uploading in bandwidth-constrained envi- 
ronments. The corresponding software component at CAD 
processing module 932 supports decompression to reconsti- 
tute the original files. 

As with other capabilities provided by the NICECAD 
system, CAD utilities/conversion plotting module has appli- 
cations to all three aspects of the overall system (NICECAD, 
GMR and ETC). There fore. it may be used by a designer to 
upload and convert an aheady-existent part design model 
file onto the system before conducting a search of the GMR 
database for qualified fabricators. It may be used by a 
designer or prime contractor (or by fabricators) to upload 
and/or convert part design model files when engaging in the 
bidding process. 

Other CAD support processing modules 1216 may com- 
prise any other processing modules supporting the 
NICECAD system's CAD fiinctionality. 
Multimedia Communications Processing 

The multimedia communications functionality has appli- 
cations to all three of the aspects of the present system. 
Therefore, the multimedia communications capability may 
be used by design team members when developing and 
evaluating a design. It may be used by a designer or prime 
contractor to engage in quasi- real-time discussions with 
potential fabricators regarding design and/or contractual 
issues. 

Multimedia communications processing module 978 pro- 
vides the multimedia communications capability of the 
system and, as depicted in FIG. 13, may comprise quasi-real 
time audio processing module 1302; quasi-real time video 
processing module 1304; quasi-real time graphics process- 
ing module 1306; and other multimedia processing modules 
1308. 

Quasi-real time audio processing module 1302 permits 
users to engage in an "on-line'* interactive oommimications 
session through NICECAD servo- system 200. In one 
embodiment, the system provides a secure environment so 
that users may engage in oral communications using quasi- 
real time audio processing module 1302 without concern 
about disclosing proprietary or sensitive information. 

Quasi-real time video processing module 1304 permits 
users to engage in a NICECAD communications session that 
includes video to thereby conduct a secure teleconference- 
like session through NICECAD server system 200 over 
network 260. 

In one embodiment, the communications support pro- 
vided by quasi-real time audio processing module 1302 and 
quasi-real time video processing module 1304 are coordi- 
nated so that video and audio are presented to each partici- 
pant in a substantially synchronized manner. In one 
example, the NICECAD system's capability for transmis- 
sion of audio and video is implemented using a software tool 
for synchronization, control, processing and presentation, 
such as Java*™ Media Framework (JMF) 1.0 API or JMF 
2.0. 

Quasi-real time graphics processing module 1306 is a 
module that may permit participants in an on-line commu- 
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nicatioas session to view graphics, such as a 3D part design event simulation module 1514; assembly simulation module 

model or 2D section cuts, rotations, fly-throughs, zooms or 1516; materials analysis processing module 1518; compo- 

pans in a substantially concurrent manner. In one nent interference analysis processing module 1520; other 

embodiment, this module may be linked or coordinated with analysis and simulation modules 1522; machining process 

a module sudi as part design model creation and editing 5 simulation module 1524; casting simulation module 1526; 

processing module 1202 (which may include a server- foiging simulation module 1528; sheet metal process simu- 

provided Java™ applet or semi- machine-dependent lation modide 1530; and other manufacturing simulation 

application) or part design model visualization and manipu- modules 1532. 

lation processing module 1210 (which may include a Java™ Stress analysis processing module 1502 may use finite 

applet). This embodiment provides a substantially real time lO element or equivalent nimierical analysis techniques to 

on-line session for creation and editing of a part design determine the stress distribution throughout in a part design 

model and/or manipulation, translation and ^Virtual cuts'* of model System dynamics analysis processing module 1504 

a part design model. This would allow, for example, one may use numerical techniques to evaluate the dynamic 

design team member to engage in the design effort with behavior of a part design model, such as resonance points, 

another remotely located design team member This would 15 acoustical properties and the like. Rotordynamtcs analysis 

allow, for example, a design team member to interact with processing module 1506 may use numerical techniques to 

a remotely located fabricator team member to view sectional evaluate behavior of rotating parts, such as to evaluate 

cuts at the same time in order to discuss prodiicibility issues. ' vibration perfonhance at a design "speed' arid through the 

In one embodiment of the invention, this functionality of the transition from startup to the design speed. Thermal analysis 

NICECAD system is provided using applications coded in 20 processing module 1508 may use numerical techniques to 

Java SD*"^ 1.1 API for supporting the transmission of evaluate a part design model at various temperatures in 

graphics over network 260. terms of stress magnitudes and deformation or weakening 

Other multimedia processing modules 1308 comprises that may afifect performance, 
any other modules supporting the NICECAD system's mul- Fluid dynamics analysis processing module 1510 may use 
timedia commimications capability. 25 numerical techniques to evaluate performance of a part 
Electronic Commerce Processing design in a fluid environment, and may include measure- 
Electronic commerce processing module 988 provides the ment of such parameters as pressure, temperature, and 
electronic commerce capability of tbe system and, as density distributions. Motion simulation module 1512 may 
depicted in HG. 14, may comprise standard contracts pro- use numerical simulation techniques to evaluate perfor- 
cessing module 1402; terms and conditions negotiation 30 mance of a part design while in motion, such as to determine 
processing 1404; contract formalization processing module interference between components or with other objects in 
1406; electronic finds transfer processing module 1408; and the operational environment, and to determine whether 
other electronic commerce processing modules 1410. pressures and forces are excessive. Mechanical event simu- 
Standard contracts processing module 1402 may be a lation module 1514 may \ise numerical techniques to evalu- 
module that permits users (such as a prime contractor and a 35 ate a part design model's behavior in response to mechanical 
supplier or fabricator) to access standard form contract events, such as crashes or collisions, and may provide 
templates (e.g., see FIG. 6, module 696). Terms and condi- predictions of the extent of deformation, dents and the like, 
tions negotiation processing module 1404 may comprise a Assembly simulation module 1516 may use numerical tech- 
module that permits users to select from a database or file of niques to simulate tbe assembly process for a part design 
standard terms and conditions (e.g., see FIG. 6, module 40 model to evaluate the producibility thereof, 
697). Contract formalization processing module 1406 may Materials analysis processing module 1518 may use 
comprise a module that permits users to formalize or enter ntunerical techniques to evaluate a part design model in 
into a contract that has been negotiated. This may include the terms of the materials to be used. For example, certain 
provision of digital signatures of one or more of the users to entities may be designed to be made of Kevlar'^, and this 
indicate their assent to the terms (e.g., see FIG. 6, module 45 analysis may be used to evaluate behavior based on the 
699). Electrcmic funds transfer processing module 1408 may properties of said material (e.g., see FIG. 7, module 331). 
comprise a module that permits funds to be transferred Component interface analysis processing module 1520 may 
electronically from one user to another. Thus, the entire use numerical techniques to evaluate the interface between 
contracting process, including drafting, negotiation and parts of a part design model, or between the part design 
funds transfer can be conducted in the virtual environment 50 model and external items. Other analysis and simulation 
Other electronic commerce processing modules 1410 may modules 1522 refers to any other modules used to evaluate 
comprise any other modules supporting the electronic com- a part design model. 

merce facilities of the system. Modules 1524-1532 are especially relevant to fabricators 

Id one embodiment, electronic commerce processing evaluating producibility of a part design model. Machining 

module 988 may comprise a platform independent client- 55 process simulation module 1524 may be used to evaluate 

side application, such as a Java™ applet, that is provided to whether a part design model (or portion thereof) may be 

facilitate the processing tasks performed by one or more of manufactured using particular machines. For example, the 

modules 1402-1410. dimensions of the part design model may be considered to 

Engineering Analysis and Simulation (EAS) Processing determine which machines may be used and what material 

Engineering analysis and simulation processing module 60 stock may be used. Casting simulation module 1526 may be 

946 permits users, such as EAS team members, to carry out used to determine whether casting processes may be used to 

various analyses and simulations and, as depicted in FIG. 15, produce a part design model. Forging simulation module 

may comprise stress analysis processing module 1502; sys- 1528 may be used to determine whether forging processes 

tem dynamics analysis processing module 1504; rotordy- may be used to produce a part design model. Sheet metal 

namics analysis processing module 1506; thermal analysis 65 process simulation module 1530 may be used to evaluate 

processing module 1508; fluid dynamics analysis processing whether the part design model may be made of sheet stock, 

module 1510; motion simulation module 1512; mechanical Other manufacturing simulation modules 1532 refers to any 
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Other manufacturing simulations that may be offered by the 
NICECAD system. 

For purposes of clarity, it should be noted that there may 
be correspondence between the analytical tools provided by 
modides 1502-1532, especially those pertaining to the pro- 
duction engineeriog disclipline, and the producibility logic 
supported by the GMR system (e.g, modtile 2650» FIG. 21). 
In general, modules 1502-1532 represent software which is 
used by de^gn team members during the design and devel- 
opment phase to evaluate a proposed design. Typically, the 
current baseline part design model (or parts thereof) is the 
input, and the output is some measure of performance or 
compliance with applicable specifications. On the other 
hand, the producibility analysis performed by module 2650 
(FIG. 21) represents analysis performed by the server for the 
purposes of generating the second query set (to be discussed 
below) for purposes of searching the GMR database for 
qualified fabricators. Therefore, while the results of * the 
producibility analysis may be made available, and while the 
substantive analysis may involve some of the same 
computations, the results are used for different applications 
in the two contexts (NICECAD and GMR searching). 

Regarding implementation of the aforementioned 
modules, in one embodiment the modules may comprise 
executable files or code that may be accessed by the user for 
downloading and execution (e.g., the NICECAD system 
may present a browser page to the user, who could then 
select fi-om a list of analysis and simulation options). In this 
embodiment, the "number crunching" associated with the 
analysis or simulation is performed by the user station 
system. In another embodiment, the aforementioned mod- 
ules are made available to users through a platform inde- 
pendent application, such as a Java™ applet, whereby the 
user may assign the inputs for the analysis (such as the part 
design model and various analysis or simulation parameters) 
and the "number crunching" is substantially performed by 
NICECAD server system 200. In this fashion, the processing 
demands on the user system are minimized, and little or no 
specialized hardware or software is required. 

It ^ould also be noted that HAS processing module 946 
(or parts thereof) may be integrated or coordinated with 
CAD processing module 932 (or parts thereof). For 
example, an analysis that requires 2D sections of a part 
design model may include the execution of a module such as 
part design model visualization and man^iulation processing 
module 1210 (FIG. 12). Access to EAS processing modules 
may be constrained by access permissions assigned by an 
approval authority (e.g^ see FIG. 11, module 1116). Check- 
out records may be stored whenever a team member 
accesses one of the EAS processing modules (e.g., see FIG. 
11, module 1104). 

Overview of a Method for a Cbncurrent Engineering Project 
using a Wnial Collaborative Environment 

FIGS. 16A and 16B provide an overview of a method for 
undertaking a concurrent engineering project in a virtual 
collaborative environment, such as that provided in the 
system previously disclosed. 

Referring to FIG. 16, a prime conUractor first assembles a 
series of teams, as in step 1602, and the prime contractor 
establishes a project on the virtual system, as in step 1604, 
which may rely on a software component such as RDM 
electronic document processing module 1102. This may 
require the creation of contracts between the prime contrac- 
tor and suppliers (FIG. 4, module 415), the prime contractor 
and the NICECAD system, and supplier(s) and the 
NICECAD system (HG. 4, module 410). NICECAD system 
server 200 may set up accounts for suppliers aix! the prime 
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contractor (FIG. 5, module 320) and basic project data in the 
database (FIG. 8, PDM data 335). User ID's and passwords 
may be established for the prime contractor and st4)pliers 
(FIG. 10, module 1002). 

S The design team may create a preliminary design, as in 
step 1606, which could be done with the assistance of a 
software component such as part design model creation and 
editing processing module 1202 of FIG. 12 and baseline part 
design model management module 1106 of FIG. U. The 

10 preliminary baseline part design model(s) (for simplicity, we 
refer to the model for a part in the singular as the part design 
model, although those of ordinary skill can appreciate that a 
design may comprise a plurality of part design models) is 
stored by the NICECAD server system, as in step 16(D8, 

IS which could be stored in stored baseline part design model 
data module 865 of FIG. 8. The design team may also create 
preliminary PDM documents, such as a system specification, 
performance specification, project schedule or other gener- 
ally non-graphical project documents, as in step 1610. This 

20 step may be carried out using a software component such as 
PDM electronic document processing module 1102 of FIG. 
11. The preliminary PDM documents are stored by 
NICECAD server system 200, as in step 1612, which may 
be in a module such as stored product data management 

25 system electronic document data module 840 of FIG. 8. 
The prime contractor may assign design and analysis 
access permissions to teams or individual team members, as 
in step 1614 (e.g., see FIG. 8. module 860; FIG. 11, module 
1116). The prime contractor may then activate the prelimi- 

30 nary PDM system, as in step 1616 (e.g., see FIG. 11, module 
1102). Those of skill in the art understand that product data 
management is a rigorous process that may involve strict 
procedures and significant documentation. In the early 
phases of the development process (such as during the 

35 creation of the initiatial design), the design may change 
significantly as different approaches arc considered and 
traded off. Consequently, a less rigorous preliminary PDM 
system may be used during the initial stages (e.g., see from 
"initial idea" to "Desigp 1," FIG. 1) so that the PDM 

40 requirements do not overburden the project at the early 
stage. 

Based on authorizations assigned by the prime contractor, 
teams perform analysis and simulation to evaluate the pre- 
liminary baseline part design noodel according to various 

45 disciplines, as in step 1618 (e.g., see FIG. 9, module 946; 
FIG. 15). Results may be stored in the NICECAD system 
(c.g., see FIG. 8, module 885; FIG. U, module 1114). The 
teams may then discuss proposed modifications to the pre- 
liminary baseline part design model based on such analyses, 

50 as in step 1620. This may be performed in the virtual 
NICECAD environment using quasi-real time video, audio 
and graphics (see FIG. 13; FIG. 12, module 1210). Records 
of these sessions may be stored (e.g., see FIG. 8, module 
890). Based on such discussions, the design team may make 

55 changes to the preliminary baseline part design model by 
modifying a working copy part design model, as in step 
1622, '"Working copy*' generally indicates that the model is 
a working copy, and does ooi necessarily represent an 
approved baseline. The working copy part design model, as 

60 modified, may then be stored by the NICECAD system, as 
in step 1624, to a working copy storage such as that of FIG. 
8, module 892. 

The prime contractor (or other approval authority) may 
approve proposed modifications to the preliminary baseline 

65 part design model, as in step 1626, based on the recommen- 
dations made by the design team and analysis team(s). This 
step could involve the creation of a digital approval signa- 
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ture (e.g., sec FIG. 8, module 870; FIG. 11, module 1112), 
although in one embodiment no such formality is required 
while in the preliminary PDM phase. The prime contractor 
may then store the new preliminary baseline part design 
model, as in step 1628. In one embodiment, this Dew model 
may be stored in module 865 of FIG. 8 and a revision history 
in module 840 of FIG. 8 would be updated. Preliminary 
PDM documents may be updated as required for the new 
design, as in step 1630. 

If the preliminary baseline part design model is still not 
sufficiently mature (decision block 1632, "No"), the prime 
contractor may request that additional analyses be 
performed, in which case the method returns to step 1618. If 
the preliminary baseline part design model is considered 
sufficiently mature (decision block 1632, "Yes"), the prime 
contractor may commence the formal PDM process, as in 
step 1634. Those of ordinary skill can understand that the 
point of "sufficient maturity" of a design is a determination 
that is based on the judgment and'cxperience of the prime 
contractor project managet(s). 

The methodology of the project development effort during 
formal PDM is similar to that of preliminary PDM, only the 
PDM management is more rigorous. Therefore, steps 
1636-1648 are performed like steps 1618-1630. During 
formal PDM, however, the documentation requirements and 
data management are enhanced. For example, as previously 
discussed, version numbers may be assigned to each base- 
line part design model and to each working copy part design 
model. A revision history of the baseline part design model 
may be maintained. Strict check-in and check-out proce- 
dures may be enforced. Digital signatures may be required 
for any change to the basehne part design model and 
associated PDM documents (specifications and the like). 

After each round of analysis and simulation, the prime 
contractor determines whether the baseline part design 
model is sufficiently mature to begin fabricating prototypes. 
If not (decision block 1650, "No"), the method returns to 
step 1<»36 for additional analysis. If the baseline part design 
model is considered mature (decision block 1650, "Yes"), 
the prime contractor may approve the final part design 
model aix) PDM documents, as in step 1652. In one 
embodiment, this may entail digital signatures approving the 
final part design model and PDM documents (e.g., see FIG. 
8, module 870; FIG. 11, module 1112). 

Al this point, contracts between the prime contractor and 
fabricators may be entered into, as in step 1654, for the 
production of prototypes. The fabrication team may then 
produce prototypes in quantity based on the final part design 
model, as in step 1656. 

A Method Using a Virtual CoUaboratiye Environment to 
Create an Initial Design 

FIG. 17 depicts a method for creating an initial design 
using the collaborative networked enviroDment. A designer 
team member (hereinafter abbreviated as ''designer'*) logs 
on to the system, as in step 1702. Hie system authenticates 
the user, as in step 1704 (e.g., see FIG. 10, module 1002). 
The designer selects NICECAD CAD software for launch, 
as in step 1706. In one embodiment, this could be carried out 
by part design model creation and editing processing module 
1202 of FIG. 12, which may be coupled to modules 1204- 
1208 for parts, drawing symbols and standards/ 
specifications to be used in creating the part design model. 
In one embodiment, the NICECAD CAD software may 
include a platform independent application, such as a Java*^ 
applet, that provides for client/server interactive CAD pro- 
cessing. In another embodiment, the NICECAD CAD soft- 
ware may include serv^er-provided semi- machine-dependent 
applications executable with standard operating systems. 
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The designer creates graphic entities that comprise a part 
design model using CAD tools and commands of the 
NICECAD CAD software, as in step 1708. CAD packages 
generally comprise a series of software tools and commands, 

5 as well known to those of skill in the art. The designer may 
use a set of attribute names to identify the entities, as in step 
1710. The designer associates attributes and attribute values 
to selected entities, as in step 1712. The designer associates 
components from standard and custom parts libraries as 

10 needed (it may not be necessary), as in step 1714. 

Steps 1710-1714 may be accomplished using data from 
certain modules, such as stored standard attribute and 
attribute values data module 845 of FIG. 8 for attributes; 
manufacturing standards and specifications data module 850 

IS of FIG. 8 for standards/specifications; stored standard draw- 
ing symbols data module 880 of FIG. 8 for drawing sym- 
bols; and standard and custom parts li*brary data module 875 
of FIG. 8 for prebiult parts. This may be accomplished using 
various processing modules, such as attributes and attribute 

20 values management module 1110 of FIG. 11; standard and 
custom parts library management module 1204 of FIG. 12; 
standard drawing symbols management module 1206 of 
FIG. 12; and maniifacmring standards and specifications 
management module 1208 of FIG. 12. 

25 The designer creates and edits PDM documents 
(preliminary or formal) to properly track the new part design 
model, as in step 1716. Processing modules sudh as PDM 
electronic document processing module 1102 of FIG. 11 and 
data modules such as stored product data management 

30 system electronic data module 840 of FIG, 8 may be used to 
carry out this step. In one embodiment, this step may 
comprise the provision of a platform independent GUI 
interface and/or application, suci as browser pages and/or a 
Java™ applet, that permits the desigi^r to select various 

35 options, such as whether to create a system ^ecification or 
performance ^ecificatioa. It may allow the designer to 
decide options for the revision history (FIG. 8, module 840) 
and whether version numbers should be assigned to all 
baseline part design models (e.g., see FIG. 8, module 865) 

40 and/or working copy part d^gn models (e.g., see FIG. 8, 
module 892). 

The system then stores the new part design model, 
attributes, attribute values, and PDM documents to the 
system, as in step 1718. Processing modules from RG. 11 

45 and data modules from FIG. 8 may be employed. 

A Method Using a \^rtual Collaborative Environment for 
Engineering Analysis and Simulation 

FIGS. 18A and 18B illustrate a method for using the 
system to perform engineering analysis and simulation using 

50 the virtual eovirormieDt Before disclosing the method, it 
should be appreciated that the terms "preprocessing," 
"analysis or simulation," and "postprocessing** are descrip- 
tive terms that represent a ftmctional allocation of the 
analysis/simulation process. Those terms are used to explain 

55 the process and are not meant to imply that the EAS analysis 
process must be segregated in a particular fashion. As those 
of skill in the art can appreciate, "preprocessing," "analysis 
or simulation," and "postprocessing** may be part of a single 
software "nm" or may pertain to several discrete acts. For 

60 example, in the case of stress analysis, there may be pre- 
processing by representing a part design model as a mesh or 
network of points ("finite elements"). Then there may be the 
finite element analysis that computes the stress at each point. 
Then there may be the postprocessing that converts the 

65 numerical results into a presentation (e.g., a graph). Those of 
ordinary skill should appreciate that such acts may be 
performed as three separate sub-analyses (e.g., a separate 
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module performing each and having its own set of results or Upon completion of the analysis or simulation, step 1S34 

ouput) or as part of a single analysis (e.g., a single module provides that team members discuss effects of the EAS 

or software component performing the entire analysis). results on the part design model. Generally, this discussion 

Returning to FIGS. 18A & B, the team member logs on to may include one or more members from the design team and 

the NICECAD system, as in step 1802, and the NICECAD 5 the particular EAS team, although this may vary based on 

system authenticates the team member, as in step 1804. The circumstances. As discussed with respect to FIG. 13, such 

team member requests access to a part design model, as in discussions may take place over the networked virtual 

step 1806. As discussed previously, there may be a plurality environment using quasi-real time audio and/or video and/or 

of part design models associated with a given engineering graphics. Based on said discussions, the prime contractor 

development project, so that the team member may seek lo makes a decision on whether a design change to the part 

access to one or more of these. design model should be effected, as in step 1836. 

NICECAD server system 200 provides access to the part If the analysis or simulation is to rely on external software 

design model and PDM data consistent widi the authoriza- (decision blodc 1810, "No*^, the team member may request 

tion for that team member, as in step 1808. As previously the download of the part design model, as in step 1826. In 

discussed, a module such as design and access permissions 15 step 1828, NICECAD server system 200 downloads the part 

management module 1116 of FIG. 11 may permit a prime design model. In one embodiment, steps 1826-1828 may 

contractor to assign access permissions for the part design include giving the team member the option to select a file 

model, PDM documents, and EAS processing modules. This ' format (e.jg., IGES, STEP, etc.) for the downloaded part 

data may be stored in a module such as stored design and design model. In one embodiment, this step may be fadli- 

analysis access permission data module 860 of FIG. 8. Using 20 tated by providing browser pages and/or a Java™ applet or 

modules such as these, NICECAD server system 200 could the like. In step 1830, the team member performs the 

permit (or deny) access to the part design model and PDM external analysis or simulation. In step 1832, the team 

data, according to step 1808. member uploads the results to the NICECAD system and 

If the EAS to be conducted relies on external programs or updates appropriate PDM documents. Steps 1834 and 1836 

processing modules (or even so-called pen-and-paper 25 are performed as previously discussed, 

analysis), the system skips to step 1826 (decision block A Method Using a Virtual Collaborative Enviroimient for 

1810, "No"). If the EAS relies on NICECAD hosted or Quasi-Real Time Interaction 

provided EAS modules, the system proceeds to step 1812 FIGS. 19A & B illxistrate a method for team members to 

(decision block 1810, **Yes'^. In the latter case, EAS soft- engage in an interactive communications session using the 

ware for the analysis may be provided by the NICECAD 30 system. As can be readily appreciated, the multimedia 

system. communications capability has ready applications in all 

In step 1812, the team member launches an EAS prepro- three aspects of the present system: the development of the 

cessing software component consistent with authorization. design, the search for qualified fabricators, and the negotia- 

As noted above, the prime contractor may assign access tion and bidding process. The detailed description below 

permission data for the EAS modules, so the team member 35 describes the communications session in the context of 

must be authorized to access that EAS software component. design development, but this is exemplary only, and the 

In one embodiment, launching the preprocessing software multimedia communications capability finds ready applica- 

component comprises running a software program that is tion in the other aspects of the invention, 

downloaded from the server and run on the team member's In step 1902, partidpating team members log on to the 

user system. In another embodiment, launching comprises 40 NICECAD system, and in step 1904, the NICECAD system 

running a platform independent application, such as a authenticates the team members. In step 1906, the team 

Java''" applet, that is interactive with NICECAD server 200 members request a secure interactive session using audio 

so that the bxilk of the processing is performed by NICECAD and/or video. In one embodiment, the system may provide 

server 200. additional levels of security for such a session, such as 

In step 1814, the team member performs preprocessing 45 providing encryption with greater key lengths. Continuing 

procedures for the analysis or simulation. In step 1816, the with step 1908, NICECAD server system 200 launches the 

team member laimches the analysis or simulation software interactive video and/or audio software componcnt(s) (e.g., 

component consistent with authorization (see step 1812 for see FIG. 13, modules 1302-1304). Steps 1906-1908 may be 

several embodiments). In step 1818, the team member carried out through the use of a platform independent 

performs the analysis or simulation, which may require a 50 application, such as a Java™ applet, 

series of computations. As noted with rei^»ect to step 1816, In step 1909, the session mediator establishes the new 

the step may comprise ruiming a platform independent session and coordinates activity among the participating 

application, such as a Java™ applet, so that the performance team members. The ''session mediator^ generally refers to 

of the analysis or simulation may actually be a shared task the team member who has respoisibility for the interactive 

between the server and the team member's user system. 55 session and acts as the ''virtual chairperson." In one 

In step 1820, the team member launches the analysis or embodiment, the session mediator establishes the new ses- 

simulation postprocessing software component consistent sion by providing the identity of the participating team 

with authorization, and in step 1822, the team member members and a description of the session (e.g., "NICECAD 

performs the postprocessing procedures. In step 1824, the session of Juo. 1, 2010, to discuss proposed design changes 

team member posts results to NICECAD server system 200 60 as a result of stress analysis") to NICECAD server 200. 

and updates appropriate PDM documents. A processing If the interactive session is not going to require a part 

module such as EAS results management module 1114 of design model (decision block 1910, "No"), the method will 

FIG. 11 and data module such as stored EAS results data skip to step 1916, discussed below, 

module 885 of FIG. 8 may be used to carry out this step. If the interactive session is going to need a part design 

While step 1824 states that the team member posts the 6S model (decision block 1910, "Yes"), the method proceeds to 

results, in one embodiment the NICECAD system may step 1912. In step 1912, the NICECAD server system 200 

provide that all EAS results be automatically stored. launches the interactive graphics software component (e.g.. 
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see FIG. 13, module 130(>). Acoordiog to step 1914, 
NICECAD system server then commeoces network trans- 
port and management of the audio and/or video and graphics 
data (e.g., see FIG. 13, modules 1302-1306). NICECAD 
server 200 retrieves the part design model requested by the 
session mediator, as in step 1922. The part design model is 
presented to the participating team members (c.g., see FIG. 
12, module 1210; FIG. 13, module 1306), as in step 1924, 
and the team members interact using audio and/or video to 
discuss design issues, as in step 1926. 

In step 1928, team members may interact by processing or 
manipulating the part design model using interactive soft- 
ware supplied by NICECAD server system 200 (e.g., see 
FIG. 12, modules 1210 and 1202). In one embodiment, 
NICECAD server system 200 permits only one team mem- 
ber to control the part design model at a time, and after each 
change, the results are presented to all participating team 
members. 

Step 1928 may be further illustrated by subdividing it into 
steps 1930-1934. In step 1930, a team member rotates or 
translates or otherwise manipulates the part design model to 
focus particular design issues. In step 1932, a team member 
applies comments or ''mark ups** to the part design model to 
highlight particular aspects of the part design model. In step 
1934, the team member applies the virtual "cutting tool" to 
generate 2D sections of the part design model. As previously 
described, module 1210 may support "fly through" 
functionality, so that users can also simultaneously view 
internal regions of the part design. 

In step 1936, a decision is made regarding the design 
issues, and the part design model and PDM documents are 
updated as required. In one embodiment, only the prime 
contraaor has approval authority for design changes. In 
another embodiment, the NICECAD system may permit the 
prime contractor to delegate this authority (such as for a 
particular interactive session) at its discretion. In step 1938, 
the interactive session is saved to the NICECAD system 
(e.g., see FIG. 8, module 890). 

Returning to the "No" branch of decision block 1910, the 
interactive session may not require the part design model, in 
which case audio and/or video may be used. In step 1916, 
the NICECAD server commences the network transport and 
management of the audio and/or video. In step 1918, the 
team members interact to discuss issues of interest, such as 
design issues, contract issues and so on. The method con- 
tinues with steps 1936 and 1938 as previously discussed. 
A Second Aspect of the Invention: A System and Methods 
for Providing a Searchable Database of Registered Fabrica- 
tors for Producing a Part Design (GMR) 

A second aspect of the invention is directed to a system 
and methods for providing a searchable registry of fabrica- 
tors whidi can be searched by a designer or prime contractor 
seeking to manufacture a product represented by a part 
design model As can be readily appreciated, the design 
(represented by a part design model and specificatiots) may 
have been developed using the previously described system 
and methods (the NICECAD aspect). In such a scenario, 
much or all of the necessary design information resides on 
the system (e.g., the three dimensional part design model 
may be stored in module 865 and the ^ecification docu- 
ments may be stored in module 840, both of FIG. 8). 
However, the overall system provides maximum flexibility 
insofar that the second aspect of the invention has applica- 
tion even where the design is not already stored on the 
system. Therefore, the second aspect of the invention, the 
searchable GMR registry, permits a designer or prime con- 
tractor to upload and, if necessary, convert an 
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independently-developed part design model in order to 
locate qualified fabricators. 
Overview of the Searchable GMR 

FIG. 20 depicts an overview of the second aspect of the 

5 invention, which is generally referred to herein as the 
searchable Gtobal Manufacnirer*s Registry (GMR). In the 
illustrated embodiment, there is GMR server system 1000, 
databases HOG, designer user systems 1200, fabricator user 
systems 1300, network interface 1600, backup server hard- 
ware and software 1400 and backup data storage 1500. 

As previously noted, the illustrated architecture is exem- 
plary insofar that GMR Sever System 1000 and NICECAD 
Server System 200 could easily be hosted on the same server 
system. For clarity, FIGS. 20-25 depict and the following 
description focuses on the second aspect of the invention as 

^5 an independent system. However, in the preferred embodi- 
ment both aspects are implemented as an integrated system. 
In that case, network interface 1600 (FIG. 20) and network 
interface 260 (FIG. 2) are the same. L3ccwise, database 1100 
(FIG. 20) and database 210 (FIG. 2) may comprise elements 

20 of an integrated database. Backup server hardware and 
software 1400 and backup data storage 1500 (FIG. 20) and 
backup server hardware and software 240 and backup data 
storage 250 (FIG. 2) could be integrated. And finally, it 
should be noted that the terms "fabricator** user systems 

25 1300 and "designer** user systems 1200 (both of FIG, 20) 
and "prime contractor*' user systems 220 and "supplier** user 
systems 230 (both of FIG. 2) arc broadly descriptive. A 
designer searching the GMR database may be the prime 
contractor, and an outsourced fabricator is considered to be 

30 a supplier. 

Network interface 1600 may comprise any network that 
allows communication amongst the components, and may 
encompass existing or future network technologies, as pre- 
viously discussed in connection with network 260 (FIG. 2). 

35 In one embodiment, use of the Internet as network 1600 is 
beneficial sin^ it may maximize the universe of designers 
and fabricators who may participate in the GMR system. 

Designer user systems 1200 may comprise any system 
capable of interfacing with network 1600. Designer user 

40 systems 1200 may comprise "standard*' computer systems 
that do not require specialized hardware or software to use 
the GMR system. Designer user systems 1200 may comprise 
personal computers or any like computer systems described 
in connection with prime contractor user systems 220 (FIG. 

45 2). In the preferred embodiment, designer user system 120 
comprises a personal computer or workstation ruiming a 
standard operating system such as Windows NT, and using 
a standard browser such as Microsoft Internet Explorer™ 
5.0 capable of interpreting HTML 4.0, XML, VRML, and 

50 running Java™ applets, so as to support a substantially 
platform-indepen^nt interface with GMR Server System 
1000. As discussed previously in cotmection with the 
NICECAD aspect of the integrated system, user systems 
such as designer user systems 1200 may comprise computer 

55 systems using a custom browser tailored to the present 
applicatioiL As before, in other embodiments, such user 
systems may be executing server-provided semi- machine- 
dependent applications, particularly for graphics-intensive 
applications, which mi^t be coded in a language such as 

60 Open GL™. Even where such applications are executed by 
user systems, a platform independent network interface can 
be maintained. 

Similarly, fabricator user systems 1300 may comprise any 
system that may interact with the central server system over 

65 network 1600. 

Backup data storage ISOO comprises a system for backing 
up the data stored by the interactive EDM system, and can 
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comprise the storage technologies and/or architectures dis- 2200; billing information processing and report generation 

cussed previously in connection with module 250 of FIG. 2. module 2250; fabricator update processing module 2300; 

Backup server hardware and software 1400 comprises one search initiation module 2320; general GMR search query 
or more backup servers, including server modules, to reli- processing module 2350; interactive designer preference 
ably support the second aspect of the invention, and may 5 module 2400; interactive designer part design model pro- 
comprise backup means discussed in connection with mod- cessing module 2450; part design model file parsing module 
ule 240 of FIG. 2. 2500; interactive designer attribute assignment module 

Databases 1100 depict the storage that may be employed 2550; user preference first query set processing module 
to store data maintained by the GMR system, inchiding 2600; producibility analysis second query processing mod- 
storage technologies discussed in connection with database lo ule 2650^ query results reconciliation processing module 
210 of FIG. 2. Databases 1100 may store the fabricator 2700; GMR designer account processing module 2750; 
specific information stored in Global Manufacturers Regis- GMR fabricator account processing module 2800; other 
try data module (e.g., see FIG. 22, block 3000), as well as server side applications 2850; quality assurance processing 
designer account data, fabricator accoxmt data, and other module 2905 and other client side interactive applications 
data. In one embodiment, databases UOO resides locally is 2900. As previously noted, where the NICECAD and GMR 
with GMR server system 1000, although fumre network aspects of the invention are integrated, some of these mod- 
technologies supporting greater bandwidth may support ules may be subsumed in similar modules described in 
"rerhote location. connectioii with the fiist aspect of the invention. 

GMR server system 1000 comprises a server system User logon authentication module 2050 may comprise a 

supporting the interactive GMR system. GMR server system 20 security module for Umiting access to the interactive GMR 

1000 interfaces with designer user systems 1200 and fabri- system. Designer service authorization module 2100 may 

cator user systems 1300 through network 1600. GMR server comprise a module that sends designer authorization infor- 

system 1000 may include the hardware and software to mation including, for example, information to tell the 

interface with designer and fabricator user systems on a designer requesting a service, such as a search request, that 

substantially platform independent basis so that the designer 25 the request may result in a bilUng action and that proceeding 

and fabricator user systems do not require their own spe- further constitutes final authorization. Contracts processing 

cializcd hardware or software. Generally, GMR server sys- module 2150 may comprise a module that ensures that 

tem 1000 includes system administration, database before a fabricator registers with the system, and before a 

manipulation, and network-related operations software designer uses the system, contracts specifying the respoo- 

modules. GMR server system 1000 may also include the 30 sibiUties of each party regarding data protection, mainte- 

specialized software, some server side and some client side nance and system usage are formalized. Report generation 

interactive, for supporting upload, conversion, processing module 2200 may comprise a module that formats and sends 

and analysis of part design models, such as two-dimensional reports requested by users that, in one embodiment, may be 

models or three-dimensional solid models. sent as browser pages or hnks to downloadable files. Billing 

GMR server system 1000 may also include the hardware 35 information processing and report generation module 2250 

and software for multimedia operations such as voice, video may be a module that processes and stores billing informa- 

and graphics, that may be transmitted over the network for tion whenever a billable transaction occurs. Billing infor- 

presentation to user systems with standard client-side mul- mation processing and report generation module 2250 gen- 

timedia support. In the preferred embodiment, where the erally automatically processes transactions as they occur 

first and second aspects of the invention are part of an 40 and, in one embodiment, may also process billing summary 

integrated system, this multimedia support is provided by reports upon user request. 

multimedia communications processing module 978 (FIG. Fabricator update processing module 2300 may be a 

13) and multimedia session records are stored at module 890 module that allows fabricators to load their fabricator spe- 

(FIG. 8). The CAD capability for permitting multimedia cific data into the database, as well as update their data when 

sessions involving the viewing and manipulation of a part 45 their background or capabilities change (e.g., the manufac- 

design model arc provided by CAD processing module 932. turing facility relocates or a new machine is purchased). One 

In one embodiment, GMR server system 1000 may be of the advantages provided by the GMR capability of the 

publicly accessible as a web site, but may provide multiple invention is that it sot only provides a searchable database 

levels of security (e.g., multiple ''firewalls") to ensure that for designers^rime contractors, but it also can function as a 

proprietary designer and fabricator data may be protected. In 50 capability management system for fabricators. The fabrica- 

addition to firewalls, strong (e.g., RSA 1024 bit) encryption tors can input, update and otherwise maintain an inventory 

may be provided to protect proprietary data. GMR server of their capabilities and experience that can be used for 

system 1000 may be accessed only by users with a user ID capability management and marketing independent of its 

and password. In one embodiment, GMR server system application for GMR searches. This incidental benefit to the 

1000 may comprise a ''back end" processing server mnning 55 GMR system provides an incentive for fabricators to register 

UNIX for the model processing and database operations, in the first instance. It also means that the burden of 

and a "front end" web server running Windows NT™ and maintaining the fabricator capability data does not rest on 

Microsoft's Transaction Server™ for network-related opera- the GMR system provider. 

tions. Of course, where the first and second aspects of the Search initiation module 2320 may be a module that 

invention are integrated, then such functions are performed 60 permits a user to initiate a search session. In one 

by system administration processing modide 902 (FIG. 9). embodiment, search initiation module 2320 may present to 

The GMR Server System the user's browser a "search page" from which particular 

FIG. 21 illustrates some of the various software compo- searches can be launched. ^ 

nents or modules of GMR server system 1000. GMR server iCjCKJeneral GMR seaicfa ^uery processing module 2350 ma y 

system 1000 may comprise user logon authentication mod- 65 b ^ module that permits a user to conduct a general search 

ule 2050; designer service authorization module 2100; con- ofi be GMR database for data that may be generally acoes- 

tract processing module 2150; report generation module sible (or nonproprietary). In one embodiment, general GMR 
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search query processing module 2350 supports searches by (known to those of skill in the art as GDT data), these data 

both designers and fabricators who wish to access general items may be extracted, converted to a neutral format, and 

information regarding registered fabricators. Generally, a tagged before storage in the object database. Part design 

so-called general search involves search criteria that are not model file parsing module 2500 may also perform a check 

directly related to a design. For example, a general search 5 to ensure that no duplicate entities exist 

may query such information as a fabricator's location, shop Interactive designer attribute assignment module 2550 

certifications (e.g., ISO 9000/9001/9002), operator certifi- may comprise a module that permits a designer to assign 

cations (e.g., are CNC milling machine operators factory attributes to entities of the stored part design model. A part 

trained?), and like information. design model may comprise a series of geometrical and 

Interactive designer preference module 2400 may com- lO topological entities, each of which may be assigned its own 

prise a module that permits a desigper to input so-called attributes (such as surface finish, material, direction vector, 

''preference" data in order to search the OMR database etc.). 

based on a limited OM R search . For a limited OMR search, In one embodiment, interactive designer attribute assign- 

the designer is not requued to upload a part design model, men! module 2550 may provide for the launch of a Java™ 

but may select a series of criteria for qualifying fabricators is applet or like miniapplication at designer user system 1200 

(such as lead times, material, lot sizes, machinist/craftsman for attribute assignment. A textual list and graphical presen- 

certifications, etc.) that are considered global. U nlike a tation of the model entities may be sent by OMR server 

g eneral search, the limite dgg jyccb may result in the search o f system 1000 to designer liser systein 1200 for presentation, 

limit ed access (or pr oprietary) fab ricator data (e.g., see FI^. A list of standard attributes (e.g., see FIG. 22, stored 

22rblocks .iiUU-J400) and, consequently, Ihis option may 20 standard attributes data module 3500) may also be sent by 

be limited to designers. In one embodiment, the designer GMR server system 1000 to designer user system 1200 to 

may select a set of preferences from a browser interface with facilitate the process. The list may include such items as 

GMR server system 1000 that, following confirmation, may feature name (so the designer may name the entity), toler- 

be temporarily stored and tagged with owner ID, session ID ance type (e.g., flatness, linear, angular, runout, etc.), toler- 

and time stamp (see FIG. 22, stored designer preference data 25 ance range, surface finish value, and fabrication standard 

module 3550). These preference inputs may then be pro- (e.g., MILSPEC, ISO, ANSI, ASME, and others known to 

cessed to generate a first query set. It should be noted that those of skill in the art). For example, the designer may also 

while a preference query may search proprietary data to input direction vectors for each entity that define the outside 

identify qualifying fabricators, the imderlying proprietary surface of the model. By keyboard entry or "point and click" 

data is generally not provided to a searching designer. The 30 use of a mouse (or similar pointing device), the designer 

fabricator "owns" the proprietary data maintained on the 1 may be enabled to select entities and assign attributes and 

GMR system, and generally only the owner can view and | attribute values. Upon completion of attribute assignment, 

edit said proprietary data. the assigned information may be associated with the entities 

Interactive designer part design model processing module stored by GMR server system 1000 in the database. It should 

2450 may comprise a module that permits a designer to 35 be noted that, in the case of a "complete" solid model (e.g., 

upload a file representing a product or part to be fabricated a STEP AP214 file), sufficient information may exist for an 

(the term part design model used herein generally refers to acceptable producibility analysis to be run without further 

such a file). According to one embodiment, the part design inputs, in which case attribute assignment may be avoided, 

model may comprise a three-dimensional (3D) solid model. User preference first query processing module 2600 may 

In another embodiment, the part design model may comprise 40 comprise a module that prepares a first query as a result of 

a two-dimensional (2D) model. In one embodiment, inter- the designer's preference inputs (see interactive designer 

active designer part design model processing module 2450 preference module 2400 above) which may be run against 

sends a page to the designer's browser that provides for the the database to identify a first results list of qualified 

launch of a client-side Java™ applet that may be executed fabricators. In the case of a limited search, this may be the 

to pennit the following operations: browse local memory for 45 end of the designer session. In a limited search, appropriate 

the file, select the file format, and upload the file to GMR results (e.g., the identity of all qualified fabricators) may be 

server system 1000. In one embodiment, interactive designer stored in the designer's account data and appropriate results 

part design model processing module 2450 may convert the (eg., referral results providing basic information about the 

uploaded part design model to a neutral or common format, designer) may be stored in each qualified fabricator's 

such as an AF214 STEP file, so that stored models share the 50 accoimt data. Notice may be then given to the designer and 

same file format. This furthers the data neutrality attribute of qualified fabricators that results have been posted. For a fill 

the invention previously discussed. In one embodiment, search, on the other hand, the first results list may be 

interactive desigper part design model processing module combined with the second results fist before posting, as 

2450 may also provide utilities for the designer, such as for described in detail below. 

the conversion of solid model files amoiig different file 55 An non-exh austive list of the t ypes of information in a 
formats, such as between IGES, STEP AP203 and AP214 pr eference query mciudes : whether the fabricator is 
model foraiats and other CAD-vendor q[>ecific formats, ISO9001 certified; whether the vendor has specified trade 
known to those of skill in the art. association afiSliations; whether the vendor is a minority- 
Part design model file parsing modide 2500 may comprise owned business or meets other requirements or standards 
a module that identifies graphical entities (e.g., geometric 60 under the federal acquisition statutes and regulations; 
and/or topological features) contained in an uploaded part whether the vendor meets the specified GMR quality assur- 
design model file and converts them to a neutral format ance rating (discussed further below); whether the vendor is 
before storage: In one embodiment, each entity may be within 1000 miles of the designer's location; whether the 
tagged with an owner ID, session ID and time stamp before vendor can support specified transportation modes, such as 
storage in an object database (e.g., see FIG. 22, module 65 air, rail, and truck; whether the vendor can operate in a 
3600). If the uploaded file contains non-graphical data such so-called "just-in-time" inventory environment; whether the 
as geometric dimensioning and tolerancing information vendor has the ability to process Catia''^ CAD/CAM design 
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data; how many MILSPEC contracts has the vendor com- 
pleted successfully; and has the vendor breached past con- 
tracts or otherwise fail to fully meet past contractual obli- 
gations. 

For a full search (which may include the upload of a part 
design model, producibility analysis and a second query, 
among other steps), producibility analysis second query 
processing module 2(50 performs a producibility analysis of 
the uploaded, converted and attribute-assigned part design 
model in order to prepare the second query set for a second 
results list of qualified fabricators. 
One Example of Producibility Analysis Logic 

As one of ordinary skill can appreciate, various steps may 
be perfonned for the producibility analysis. According to 
one embodiment, the steps performed ensure that the mate- 
rial from which a part is to be made is compatible with any 
preferred processes selected by the designer. If no preferred 
processes are specified, all processes for which the material 
may be acceptable are identified for inclusion in ib& second 
query set. 

Each surface entity may be checked for a direction vector 
defined by the designer; if none exists, the system attempts 
to define a direction vector for all surfaces in order to permit 
an interference check. Each surface may be then projected 
along its direction vector in order to check for interference. 
If interference exists, then the conflicting surface entities are 
noted and the designer may be given appropriate notice (e.g., 
by e-mail) so that the conflict may be resolved (e.g., by 
modifying the attribute as^gnment). The results of the 
interference check may be used to ensure that designer- 
selected processes are appropriate for the part, particularly to 
ascertain any machine tool/die interference in the case of 
machining, forging, sheet metal and other such processes. 
For example, a forged part must have surfaces shaped in 
such a way as to permit a die press (e.g., drop forge) to fall 
along a straight path when the blank is stmck. For example, 
a complex part may not be machinable, but may be cast and 
then fini^ied with slurry processing and machining pro- 
cesses. If no processes are specified by the designer, all 
appropriate feibrication processes identified by this analysis 
may be included in the second query set. 

The system may perform a volume approximation of the 
part represented by a 3D part design model in order to assess 
producibility using various processes, such as casting, where 
volume may be an important consideration. 

The part design model may also be evaluated for the 
existence of passages or voids (e.g^ closed channels^ holes 
and other internal features that may require material 
removal). The size and topology of these passages or voids 
may be evaluated for producibility u^ng various processes, 
such as machining, ^ere passage topology may be an 
important consideration. 

The part design model may also be evaluated based on an 
envetope enclosing the part represented by the model. The 
dimensions of the envelope may be used to assess which 
machines may be used to manufacture the part and also what 
material stock may be used. For example, a cylindrical part 
will likely be made using a lathe and may require rod stock 
of a certain size. 

The producibility analysis steps may also estimate the part 
design model thiclmess to determine if the part may be made 
of sheet stock, and to what extent specific features or entities 
may be produced using sheet metal processes. 

Each entity assigned a tolerance may be evaluated for 
whether it may be achieved for the selected processes. If no 
process is specified, all processes capable of achieving the 
desired tolerance may be included in the second query set. 
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The part design model may be evaluated for topological 
symmetry to estimate the suitability of symmetrical manu- 
facturing processes such as spirming or lathing. Acceptable 
processes may then be included in the second query set 

s For each surface finish specified by the designer, all 
fininJiing processes capable of achieving that fini^ may be 
identified and included in the second query set. Each speci- 
fied surface finish, as well as each tolerance, may also be 
evaluated to ensure compatibility with the overall part 

10 design model topology. 

As one of ordinary skill in the art can appreciate, there are 
a multimde of variations of the produdbility analysis that do 
not depart from the spirit of the invention disclosed herein, 
which is to employ some automated logic to perform part- 
is specific analysis in order to identify fabricators. 

Producibility analysis second query processing module 
2650 may be a module that uses the results of the produc- 
ibility analysis to prepare a second query set". The second 
query set may be compared to databases UOO to generate a 

20 second results list of qualified fabricators. In one 
embodiment, the raw produdbility analysis results, includ- 
ing producibility analysis methodology, may be also be 
stored and made available to the designer. 

When a full search (i.e., using the first query set based on 

25 preference data and the second query based on the part 
design model/producibility analysis) is conducted, multiple 
sets of qualified fabricators may be produced. A predeter- 
mined number, such as two sets, may be produced, for 
example, one set corresponding to eadi query. Query results 

30 reconciliation processing module 2700 reconciles the pro- 
duced fabricators to render a single list of qualifying fabri- 
cators (e.g., for two sets of results, those appearing in both 
result lists). If the results cannot be reconciled (e.g., there are 
no qualified fabricators appearing in both lists), the results 

35 may be analyzed to identify the most likely cause of the 
reconciliation failure. This information may then be stored 
in the designer's results report 

GMR designer account processing module 2750 may 
comprise a module that maintains and updates all account 

40 data for each designer. In particular, this module may 
provide that records are stored for each designer session (a 
designer session may be one complete cycle of a search), 
including the search results, as well as all transactions (a 
designer transaction refers to any time the designer logs onto 

45 the system, such as to retrieve results or have a custom report 
prepared). In one embodiment, GMR designer account pro- 
cessing module 2750 may provide that a designer user ID, 
session ID, time stamp and descriptive information 
(including the search results) be stored following each 

50 completed session. In one embodiment, GMR designer 
account processing module 2750 provides that a designer 
user ID, session ID, and time stamp are stored following 
each transaction (e.g., if the designer 99 logs on to have the 
results from sessions 101 and 102 downloaded at 1:30 p.m., 

55 then all of this information may be recorded as a 
transaction). 

GMR fabricator account processing module 2800 is simi- 
lar to GMR designer account processing module 2750, only 
the former may record account data for each registered 

60 fabricator. GMR fabricator accouint processing module 2800 
may store records for each session (a session may be a 
general search by the fabricator, GMR input/update of 
fabricator specific data, or the referral results emanating 
from a designer search that identified this fabricator as 

65 qualified) and each fabricator transaction (a fabricator trans- 
action refers to any time the fabricator logs onto the system, 
such as to retrieve referral results or have a report 
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geaerated), or may only Store some sessions or traosactioDs. Account data 3900 may comprise account data maio- 

In one embodiment, a fabricator user ID, session ID and time taioed by the system for designers and fabricators. In one 

stamp may be recorded for each session and transaction. For embodiment, account data 3900 may comprise both session 

example, when a designer search identifies a particular records (such as searches, including search results; referrals, 

fabricator as qualified, the referral results may be po^ed in 5 including description of the referring designer; OMR 

the fabricator's account by this module. updates; etc.), and transaction rccoids (such as results 

Quahty assurance processing module 2905 comprise a retrieval, report printouts, etc.). Account dato 3900 may be 

module that provides the quality assurance rating capability j^^her logicaUy divisible into designer account data module 

of the system. Following the F«rformance(or U^^ thereof) fabricator account data module 3850. Where the 

of a fabncation effort by a GMR^re^ered f^bnc^to^ the nICECAD aspects of the system are part of the 

pnme contractor is given an opportunity to provide feedback . ^ . ... ^ ^ ^ , ^ ^iaaa i 

io the GMR system regarSng performance in terms of jntegrated embodmient, account data 3900 may be com- 
timeliness, quality, and oOier relevant considerations. In one ^"jf ^^«>^'it ^^^^ ^^0 of FIG. 3. 
embodiment, GMR server system 1000 may be accessed by ^""^^^V assurance data module 3605 comprises qu^ity 
the prime contractor for browser pages or the like to provide assurance data collected reflectmg the performance of fab- 
a performance assessment. The quality assurance survey 15 ricators on the GMR system. The module may comprise 
may include a series of questions which can be answered both the underlying data submitted by designers/prime oon- 
quantitatively (e.g., answered as 1-5, with "5" being "excel- tractors using electronic survey forms or the like, as well as 
lent** or "strongly agreed" and "1" being '*poor** or "strongly the aggregated GMR' quality assurance rating that derives 
disagree"). Such data can be compiled and statistically therefrom. While FIG. 22 depicts quality assurance data 
aggregated into a series, or one overall, quality assurance 20 module separate firom GMR data module 3000, it should be 
rating. The quality assurance browser forms may also appreciated the GMR quality assurance rating(s) are search- 
include questions to be answered in a narrative manner, not able by system users. For example, a preference query (to be 
necessarily to be compiled, but to be made available to discu^ed below) might include criteria regarding quality 
subsequent users of the GMR system. Quality assurance assurance rating, such as to identify only fabricators with a 
processing module 2905 supports not only the collection and 25 net rating of "3" or better. 

compilation of such data, but also the distribution of the data Global Manufacturers Registry (GMR) data module 3000 
to system users. comprises fabricator specific data stored for registered fab- 
Other server side applications 2850 refers to any other ricators. As indicated by the arrows on FIG. 22, the module 
predominantly server side applications run by GMR server may contain both general access (non-proprietary) data and 
system 1000 to support the interactive EDM system. For 30 limited access (proprietary) data. In one embodiment, lim- 
example, this module may include software for system ited access data may be directly accessible only by the owner 
administration, database manipulation, and network-related (e g«> the fabricator that submitted the data). In one 
operations. This module may include software to support embodiment, the data owner may also give authorization for 
multimedia applicationssucbastbe transport of voice, video particular users to access the owner's proprietary data. In 
and graphics over the network. 35 general, the interactive GMR system itself may issue queries 
Other client side interactive applications 2900 refers to that search both types of data to locate qualified fabricators 
any other predominantly client ade applications that may be in response to a designer search request. This may be the 
supported by GMR server system 1000. For example, if case even though the results presented to the designer 
multimedia operations require specialized capabilities contain no proprietary information, 
exceeding standard user system multimedia support, other 40 As those of ordinary skill should appreciate, GMR data 
client side interactive applications 2900 may provide those module 3000 may contain a multitude of different types of 
capabilities in the form ofdownloadable executable code. In fabricator information that may be used for designer 
one embodiment, such client-side capabilities are supported searches, so that the categories depicted below are iUustra- 
through the use of machine independent Java™ applets tive only and non-exhaustive. 

supported by standard browsers. 45 General information group data module 3250 may contain 

The Gtobal Manufacturer's Registry (GMR) Database general information, such as location, certifications and 

Databases 1100 contains the data used by the GMR afSliations, transportation modes, CAD capabilities, trade 

system. Internal analysis criteria data module 3450 repre- restrictions (import/export tariffs, technology transfer 

sents any stored constants and other data used to implement restrictions, etc.), electronic commerce capability, computer 

the producibility logic (e.g., see FIG. 2, module 2650). 50 hardware/software capability, status as federally-recognized 

Stored standard attributes data module 3500 represents minority-owned, small business or other special categories, 

attributes, and may also include attribute values, that may be and other items not related to specific machinery or manu- 

made available to designer user system 1200 to select for facturing capabilities. 

attribute assignment (e.g., see FIG. 2, module 2550). In one Process machinery group data module 3200 may contain 
embodiment, this data may be transmitted to an applet 55 information pertaining to the machinery and processes used 
launched at designer user system 1200 so that the designer by the fabricator. Information such as machine models, stock 
may readily assign attributes and values to selected graphi- types and sizes, tolerances associated with the machine, 
cal entities. In the integrated embodiment, module 3500 is production rates, lead times, set-up costs and times, numcri- 
integrated with module 845 of FIG. 8. Stored designer cal control systems, and other information may be included, 
preference data module 3550 may comprise stored prefer- 60 Since different machines may support different processes, 
ence data that may be input by the designer for the first query the inputs may vary from machine type to machine type. For 
set (e.g., see FIG. 2, module 2400). Stored designer part example, a forging process may have a different input set 
design model data module 3600 may comprise the stored than a vertical mill. Information about specific process 
part design models, including graphical and non-graphical capabilities may be included, such as elecU"o-chemical 
entities and any associated attributes. As noted above, in one 65 machining, core casting, investment casting and powdered 
embodiment, each entity may be appropriately tagged to metal processing. Information pertaining to outsourced pro- 
facilitate data management cesses may also be included. 
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Tool set group data module 3150 allows a fabricator to sylvania fabricators), certifications/affiliations and CAD 

catalog standard and custom tools used by machines. In one capabilities through the browser at designer user system 

embod^ent, standard machioe tool lists (listing such items 1200. 

as end mill cutters, drills, abrasives, etc.) may be provided Based on input criteria selected by the designer, GMR 

to limit the amount of information required by the fabricator. 5 server system 1000 prepares a query set appropriate for the 

In one embodiment, an interactive appUcation in the form of ge°f search as in step 4320, which may then be run 

a Java™ applet may be provided to fabricator user system 8/°^.^^^ a«»ss fabncator data, as in step 4340, to 

1300 so that custom tools may be buiU interactively from a ^^^°^'^L^n"''^l''T.Tn ^^""^ ^! I 

component list (e.g., see FIG, 21, module 2300). ^'^^ ^^^O and 4340 may be earned out by a software 

n I 7 j» J.1 -11 AA * • component such as the general GMR search query process- 

Pei«)nnel operator group data module 3100 may con ain lo ^^^^^ ^350 depicled in FIG. 21. Hic residti of the 

mformation about the machimste craftsman and operators ^^^^^^ ^^^^ carried out by step 4340 may then be stored 

of machmes and processes, mcludmg years of expenence ^ ^^^^ ^^^^^ ^ ^ 

and any certifications. In one embodmient, pnvacy may be requesting designer, as in step 4380. 

maintained by limiting input to non-personal data. embodiment, the general search results may be 

Materials group data module 3300 may comprise infor- 15 tagged with a user ID, session ID and time stamp before 

mation regarding those materials the fabricator can work. storage in the designer account, such as that depicted as 

For example, maximum and minimum stock sizes, stock designer account data module 3800 of FIG. 22, so that the 

types (e.g., billet, rod, bar, sheet, powder, etc.) and material designer may later retrieve them when desired. Thus, step 

types (e.g., steel, aluminum, titanium, etc.) may be specified. 4380 may encompass a subsidiary step of GMR server 

In one embodiment, the fabricator may select from a stan- 20 system 1000 issuing an e-mail to the designer giving notice 

dard Ust of materials, including material stock types, pro- that the results have been posted. Upon such notice, the 

vided to the fabricator. designer may log onto the system to retrieve the results by 

Manufacturing standards data module 3350 comprises selecting the appropriate session in the designer's account 

data regarding those standards to which a fabricator can for output as a report, to be discussed later in connection 

manufacnireapart(e.g.,MILSPEC,ISO,ANSI,ASME,and 25 with FIG. 24. 

others well known to those of ^1 in the art). Once the search has been conducted and the results 

Inspection/QA data module 3400 comprises fabricator- posted, the designer account data may be updated to reflect 

specified data regarding inspection processes, equipment completion of the task (including storage of the results), as 

and apphcable standards. In other words, the fabricator may in step 4280, as well as the corresponding fabricator accoimt 

specify what methods are used to verify that a part has been 30 data, which may be updated for those fabricators identified 

made to designer specification and under wbat standards as a result of the search, as in step 4400. Steps 4280 and 

inspections are conducted. 4400 may be carried out by software components such as 

As should be appreciated by those of ordinary skill, a those depicted as modules 2750 and 2800, respectively, in 

variety of database structures and database management FIG. 21. Finally, any applicable billing information may be 

programs may be used for databases 1100. In one 35 generated and sent to the designer, as in step 4420, and to 

embodiment, an object-oriented database structure may be fabricators identified as a result of the search, as in step 

employed combining Oracle 8™ and ObjectStore™ 4440. These billing processing steps may be carried out by 

software, well known to those of skOl in the art. a software component such as module 2250 of ¥IG. 21, and 

A Method for a Search Session using the GMR System may be stored in designer account data module 3800 and 

According to an embodiment of the present invention, a 40 fabricator account data module 3850 of FIG. 22. 

method for a designer search session using the GMR system ^ ^ Returning to the "no'* branch of decision block 4040, the 

is described in FIG. 23. Referring to FIG. 23, the designer r designer may desire a search of thfi <:n!ir^,.^brK^T(>r 

first log^ onto the interactive system, as in step 4000, by database, including proprietary data. As previously 

connecting designer user system 1200 to GMR server sys- mentioned, the preferred embodiment provides that a limite d 

tem 1000 through network 1600. The system is generally 45 s earch searches proprietar y data to identif y q ualified fabri - 

preferred to be secure, so that GMR server system 1000 catorslo.a. scarcbipgdesi gner. but the underlying proprietary 

authenticates or verifies that the designer is an authorized data is not revealed to the designer. In this case, fecjlcsig ncr 

user, as in step 4020. GMR server system 1000 may carry ma v_ select betwccp _a_l imitcd^ preference search or fiiU^ 

out this function through a software component such as user s carclgJ.accordip g _to step_40(i0. As disc ussed above in 

logon authentication module 2050, depicted in FIG. 21. so connection with the system of FIG. 21, a li mited prpfjerencc. 

Following authentication, the designer selects the scope se arch may result in a first query set, and first q uer y resul ts 

of services that are requested for the search session. Accord- l ist, without necessitatin g a producibility analysis. A full 

ing to one embodiment, the designer may select a general se arch uses the p art design i[nodeI,aBdjb e producibU jly 

search of non-proprietary data, as in step 4040. Tlie non- a nalysis so th at a second quer y set and second query results 

proprietary data may be data such as that stored in general 55 li st may be ;^odufied. If the user desires a limited preference 

information group data module 3250, depicted in FIG. 22. In search, tbemetbod skips to step 4160, to be discussed below. ^ 

one embodiment, the designer makes this selection from a Othervrise, the designer may upload a part design model 

search page presented on a browser at designer user system to GMR server system 1000, as in step 4080. Interactive 

1200. This may be performed by a software component such designer part design model processing module 2450 may 

as search initiation module 2320, in FIG. 21. 60 perform step 4080 using a platform independent Java™ 

If the designer requests a general search, then the designer applet. Where the ^fICECAD and GMR aspects of the 

may select search criteria for the search of non-proprietary invention are integrated, the part design model may have 

data, as in step 4300. For example, GMR server system 1000 been previously created (e .g., using CAD processing module 

may transmit a list of options for each of the data items 932 of FIG. 12) and stored (e.g., at PDM data 335 of FIG. 

contained in general information group data module 3250. 65 8). In that case, step 4080 of uploading the part design model 

Accordir^ to this embodiment, the designer may select may not be required because it is already stored on the 

options such as desired location (e.g. East Coast or Peon- system in a neutral format. 
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Id step 4100, GMR server system 1000 parses the part 
desiga model received from a designer into its constituent 
graphical and noD-graphical entities that may be tagged and 
stored into an object-oriented database, such as the that 
depicted as stored designer part design model data module 
3600 of RG. 22. The designer may then assign attributes 
(and attribute values) which may be associated with the 
entities stored with the part design model, as in step 4120. 
The step of attribute assignment may be carried out by a 



According to this embodiment, the designer may request a 
''standard** report detailing the query results from selected 
search sessions ("Query Results"), or a "custom** report 
summarizing transactions in which the designer has engaged 
("Designer Custom Report"). In one embodiment, source 
data for both options may be stored with the designer 
account data, such as in designer account data module 3800 
in FIG. 22. 

If the designer wishes a standard report of query results. 



software component such as that depicted as module 2550 of lo the designer selects the desired query results from the 
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FIG. 21. As with step 4080, in the integrated embodiment of 
the invention, the complete, attribute-assigned part design 
model may already be stored, in which case step 4120 is not 
necessary. 

Once the stored part design model is sufEiciently 
complete, in step 4140, producibility analysis (details of 
which are provided above in connection with module 2650 
of FIG. 21) may be performed to generate a second query 
set. As indicated above, the producibility analysis results 
may be considered intermediate to the extent they are 
primarily used for generating the second query set; however, 
the raw results and underlying methodology may be made 
available for the designer's consideration. 

Step 4160 provides for the designer to select preference 
input criteria in order to conduct a search based on general 
parameters, as previously discussed. Step 4160 may be 
performed by a software component such as interactive 
designer preference module 2400 of FIG. 21, and may 
include the provision of a Java™ applet to facilitate pref- 
erence selection. Based on the preference input criteria, a 
first query set for searching the database may be generated 
by GMR server system 1000, as in step 4180. 

Once these query sets (e.g., the first query set in the case 
of a limited search and both the first and second query sets 
in the case of a full search) are generated, those sets are 
compared to the GMR data, as in step 4200. The query sets 
may be compared to all of the fabricator data, as depicted as 
GMR data module 3000 in FIG. 22, or only a subset of such 
data. In the case of a full search, two sets of results may b e 
obtain ^, in which case step 4200 m ay include the applica- 
tion ~ofreconciliation logic to comPme t ne resultTlnto a 
singj e^set (e.g., see FIG. 21, m odule 2700)7 ut course, as 
should be appreciated bv those o fSr^ary skill m the artTthe 
need'for reconciliation logic may be obviated by siSSply^ 
^repotting both sets of results. 

In step 4220, th e search results for the limited/full se arch^ ' 
ma y be saved into d esigner account data mochJe_3800 7e.g., 
re porting qualified fabricato rs) and fabricator account data 
module 3850 (e.g., providing a referral describing the 
designer for which each fabricator has been qualified). 
Similar to step 4380, step 4240 provides for the query results 
to be sent to the designer, which may simply encompass an 
e-mail informing the designer that the results are posted and 
available for retrieval. Other notification may also be pro- 
vided. Similarly, step 4260 provides for the referral ema- 
nating from the search to be forwarded to qualified 
fabricators, which may also encompass an e-mail notice. 

Steps 4280 and 4400-4440 are repeated substantially as^ 
previously described. 

A Method for a Designer to Retrieve Reports Using the 
GMR System 

According to an embodiment of the present invention, a 
method for a designer to retrieve reports from the interactive 
GMR system is described in FIG. 24. Referring to FIG. 24, 
the designer may log on according to step 5000, and may be 
authenticated according to step 5020. Next, the designer 
selects the type of report to be generated, as in step 5040. 



designer account, as in step 5060. In one embodiment, one 
or more browser pages listing past search sessions may be 
sent to designer user system 1200, along with various report 
format options, so that the designer may select and transmit 
the desired options back to GMR server system 1000. 
According to step 5080, GMR server system 1000 then 
retrieves the selected data from the designer account and 
formats the report as requested. According to step 5100, the 
report may be then transmitted to the designer. In one 
embodiment, the designer may be given the option of 
viewing the report directly as browser pages or of linking to 
a file for download as a standard word processing text 
document (e.g., in Microsoft Word™, Word Perfect™, etc.). 
The designer account data may be updated to reflect this 
transaction, as in step 5120. 

If the designer desires a custom report, then the designer 
selects custom report options according to step 5140, which 
permits a search of the designer's entire account, including 
session records, transaction records, and billing records, for 
example. 

According to one embodiment, step 5140 may include the 
use of a Java''** applet sent from GMR server system 1000 
to facilitate the custom reporting option, which may include 
report format options. Based on the custom report options 
selected by the designer, GMR server system 1000 generates 
an appropriate query set, according to step 5160, which may 
then be run against the designer account data, according to 
step 5180. The results of the query may be retrieved and 
formatted for the report, according to step 5200. The report 
may then be transmitted to the designer, pursuant to step 
5220, which, in one embodiment, entails browser pages 
and/or a link to a downloadable file. As before, the designer 
account data may be updated, as in step 5240. 
A Method for a Fabricator Session Using the GMR System 
According to an embodiment of the present invention, a 
method for a fabricator session using the interactive EDM 
system is described in HG. 25. Referring to FIG. 25, the 
fabricator logs on to initiate the session, as in step 6000, and 
GMR server system 1000 authenticates the fabricator, as in 
50 step 6020. The fabricator selects an option, as in step 6040, 
which may inchide a "Generate Report" option, "Update 
Database" option, or "General Search** option. 

If the fabricator selects the "General Search** option, the 
steps performed may be similar to those for a designer's 
general search (see FIG. 23, steps 4300-4380). The fabri- 
cator selects input criteria for the search of non-proprietary 
data, according to step 6160; GMR server system 1000 
generates an appropriate query set, according to step 6180; 
the query set may then be run against general access 
fabricator data, according to step 6200; the search results 
may be stored in the fabricator account, according to step 
6220; and the search results may be sent to the fabricator, 
according to step 6240; and the fabricator account data may 
be updated to reflect the search session, according to step 
6260. 

The "Update Database** option may be selected if the 
fabricator wishes to update he fabricator data stored in GMR 
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data modiUe 3000. Accordingly, step 6060 provides for the which, in one embodiment, may be via browser pages sent 

fabricator to select the database components that are to be from GMR server system 1000 listing all referrals in the 

updated. For the GMR database allocation depicted as GMR account. Based on the fabricator's selection, GMR server 

data module 3000 in FIG. 3, the fabricator might select, for system 1000 then retrieves the appropriate referral results 

example, the process machinery group data stored in module 5 and formats the report, as in step 6260. The report may then 

3200 to reflect the purchase of anew madiine.AccoFdiqg to be sent to the fabricator, as in step 6280. The fabricator 

step 6080, the fabricator may then update the selected account data may then be updated to reflect the transaction, 

database component with the appropriate information, as in step 6300. 

which may be then sent to back to GMR server system 1000. The "Fabricator Custom Report" option may be selected 

In one embodiment, GMR server system 1000 may facilitate to if the fabricator desires a customized report from the fabri> 

the update by sending browser pages to the fabricator cator's account data. This option permits a search of the 

containing the existing information for that component, fabricator's account, similar to that for a designer custom 

which the fabricator may then amend before selecting a send report (discussed above). The fabricator selects the report 

command on the browser page. Step 6100 provides for GMR options, according to step 6320, which, in one embodiment, 

server system 1000 to save the updated &bricator infoima- is may be facilitated through a server-supplied Java™ applet, 

tion to the appropriate location in the database (e.g., see FIG. Thereafter, GMR server system 1000 prepares a query set 

22, process machinery group data module 3200). Once the based on the selected options, as in step 6340, which may be 

database has been successfully updated, a confirmation " mn against" that fabricator's account, as" in istep 6360. GMR 

notice may be sent to the fabricator, as in step 6120. Finally, server system 1000 retrieves the data and formats the report, 

the fabricator account data may be updated to reflect the 20 as in step 6380, transmits the report to the requesting 

update session, as in step 6140. fabricator, as in step 6400, and updates the fabricator 

The "Generate Report" option may be selected if the account data to reflect the transaction, as in step 6420. 

fabricator wishes to view a report. In this embodiment, three A Third Aspect of the Invention: A System and Methods for 

categories of fabricator reports may be supported, as Providing an Electronic Trading Community for a Part to be 

reflected by the three paths emanating from decision block 25 Built 

of step 6160. If the fabricator wishes to review stored The third aspect of the invention provides an electronic 

fabricator information in the database to ensure it is current, trading community (ETC) whereby a prime contractor/ 

then the "Fabricator Infonnation Report** option may be designer with a part design model can electronically solicit 

selected. Accordingly, GMR server system 1000 retrieves bids or proposals by issuing a request for quote (RFQ) or 

the stored fabricator data (e.g., data for that fabricator ID 30 request for proposal (RFP) to fabricators. In the preferred 

contained in GMR data module 3000, FIG. 22) and formats embodiment, the ETC capability of the system is integrated 

the report, as in step 6180. The report may then be trans- with the first and second aspects of the invention, the 

milted to the fabricator, as in step 6200, which, in one NICECAD capability for virtual collaborative engineering, 

embodiment, may be accessed either as platform indepen- and the GMR capability for identifying qualified fabricators, 

dent browser pages or a link to a formatted text file. Finally, 35 In that embodiment, a prime contractor may utilize the 

the fabricator account data may be updated to reflect the NICECAD capability to create a part design model, stored 

transaction, as depicted by step 6220. > at a server in a neutral format, in the virtual engineering 

It is noted that the "Generate Report" and ''Update environment. The prime contractor may then utilize the 

Database" options for a fabricator session represent one GMR capability to identify a pool of qualified fabricators, 

embodiment of supporting the so-called ''capability man- 40 The prime contractor may then utilize the third aspect of the 

agement system" previously mentioned. That is, the stored invention to solicit bids from this pool, or from a subset of 

fabricator data on the GMR database is not only used to the pool if the prime contractor decides to exclude certain 

facilitate searches by designers hoping to identify qualified fabricators for some reason. 

fabricators, but it incidentally also provides a ready means FIG. 26 provides a high-level functional diagram of the 

for fabricators to manage their resources and information. 45 ETC capability of the system, including GMR user 2600, 

This provides a substantial benefit to fabricators listed in the GMR provider 26S0 and manufacturing vendors 2680. 

GMR registry because it obviates or greatly reduces the need GMR user 2600 represents a designer or prime contractor 

for using internal hardware, software and human resources seeking to out-souroe the manufacture of a product for 

for capability management. This provides a substantial ben- which there exists a part de^gn model. GMR user 2600 will 

efit to the GMR provider and participating designers becaxise 50 select vendors for participation in the RFQ/bid process, as 

it may induce fabricators to "enroll" in the registry in the indicated by block 2602. As noted, in the integrated system, 

first instance. Thus, fabricators otherwise not inclined to list GMR user 2600 may select all or a part of the list of qualified 

with the registry may do so because of the benefit of the fabricators emanating from a GMR search according to the 

substantially cost-free capability management resource they second aspect of the invention. In an alternative 

will receive. These are significant benefits. In fact, a pre- ss embodiment, the ETC RFQA»id process may be undertaken 

ferred embodiment may present options for viewing/ with one or more manufacturing vendors not previously 

modifying fabricator data exphcitly as the "Manufacturer registered or otherwise associated with the system. In such 

Capability Management System," so as to highlight this a case, GMR user 2600 may provide identification and other 

beneficial aspect of the GMR system. In presenting it as information to GMR provider 2650 so that the fabricator(s) 

such, the GMR provider may also highlight the fact that it 60 can access the system to participate, 

is network-based (e.g., "Internet Accessible" or "World GMR user 2600 submits a request for quote to GMR 

Wide Web Accessible" or the like) and secure (e.g., "All provider 2650, the request comprising design and spedfi- 

Proprietary Information Securely Maintained"). cation data, such as part design model data, and associated 

The "Fabricator Referrals Report" option may be selected manufacturing specifications, as depicted in block 2604. If 

if the fabricator wishes to view referral results saved in the 6S the part design model was created and stored using the 

fabricator account data. The fabricator selects the desired NICECAD aspect of the system, the part design model and 

referral results from the fabricator account, as in step 6240, specification data can be provided by giving access permis- 
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sioDS to specified fabricators, as discussed previously in tractor. As discussed previously in oonnection with the 

coDoection with stored desigp and analysis access permis- graphics and CAD capabilities of the invention, the viewing 

sioD data module 860 of FIG. 8. Based on the bids submitted, and the various manipulations of a part design model (and 

GMR user 2600 will select one or more winning bidders, as associated features) could be accomplished by means other 

in block 2606, Upon award, GMR user 2600 submits a 5 than Java*™ -enhanced browsers. Custom browsers could be 

complete part definition to the winning bidders), as in block used. Also, server-provided semi- machine-dependent appli- 

2608. We caU what is cventuaUy provided a "complete" part ^^^^^ ^^ij be used as well 

definition because what is initiaUy provided may be a 28 fllustrates that the ETC aspect of the mvenUon 

tower-fidelity data set (e.g., lower resolution graphical data) supports mteractive graphics manipulation, similar to that 

J TT ' previously discussed m connection with the multimedia 

which IS adequate for purposes of the bidding Proc^^^Von lO ^^^^^^^^i^ns processing module 978 (FIG. 13) and CAD 

completion of the bidding prooe^ c»mpl^^^ processing module 932 (FIG. 12). GMR graphics server 

data IS provided to the selected bidder (the 'burner' ) who ^^^^ ^^^^ ^^^^ contractor design engineers 2812 and 

will actually be fabncatmg the part. manufacmring vendor engineers and craftsmen 2814 to 

GMR provider 2650 represents the server-based system interface via enhanced browsers (bbcks 2808 and 2806) to 

providing the ETC capability and communicating with 15 engage in a quasi- real-time interactive session supporting 

GMR user 2600 and manufacmring vendors 2680 through a pan, zoom and fly-throughs, posting of new versions, 

secure networked interface. GMR provider 2650 supports manipulatioo and rotation (collectively, block 2802), and the 

so-called transaction mediation (block* '2652) between a ' attachment and viewing of specification data, markups and 

prime contractor and bidding manufacturer(s) by supporting links to applicable standards (collectively, block 2804). 

terms and conditions negotiations 2654, contract formaliza- 20 Again, it bears reiteration that such interface means could be 

tion 2656 and digital signatures 2662, electronic funds other than Java™ -enhanced browseis, including custom 

transfer 2658, and multimedia services 2669. Transaction browsers and/or server-provided applications executed 

mediation generally occurs after a prime contractor selects using standard operating systems, llie network interface 

one or more winning bidders, and involves the formaUzation between users and a server(s) is maintained as substantially 

of an agreement corresponding to the selected bid. In this 25 platform independent. It is also noted that other engineering 

context, muhimedia services 2669 refers to communications data logically associated with features of the part design 

functionality supporting qua^-rcal time audio, video, and model may be viewed as well. The various types of 

graphics, including CAD functionahty supporting viewing specification, standards, and other engineering data that may 

and manipulation of a part design model as previously be logically associated with a part design model was dis- 

discussed. 30 cussed earher in detail. 

Manufacmring vendors 2680 represents fabricators bid- Collectively, FIGS. 26-28 illustrate how the networked 
ding in response to an RFQ or RFP submitted by GMR user CAD and multimedia communications features of the first 
2600. Manufacturing vendors 2680 may view 3D part aspect of the invention (NICECAD) can be beneficially 
design models and associated specifications, as in block applied to support the ETC RFQ and bidding process. In 
2682. The ETC system may permit a prospective bidder to 35 sum, the quasi-real-time "streaming" of audio, video and 
view the pool of bidders before preparing and submitting (or graphics through a GMR provider provides a means for the 
revising/updating) a bid, as illustrated by block 2684. For prime contractor and bidder to engage in detailed technical 
example, in one embodiment a ^'bidding pool list" identify- discussions from different locations, in a secure 
ing the dollar amount of the various bids is available to the environment, and substantially without the need for special- 
bidders. The bidding pool list does not identify the bidders 40 ized hardware and software. It can be appreciated that 
or disclose any detailed information provided by them to numerous aspects of the so-called "boundaries" difficulty, 
GMR user 2600. This fist might indicate: "Bidder A: S25, previously described, are ameliorated or eliminated. 
000.00; Bidder B: $32,000.00, ..." and so forth. Ultimately, Continuing with the ETC aspect of the invention, the RFQ 
a successful bidder will product and deliver parts, as in block may be submitted or ''posted" to GMR graphics server 2710 
2686. 45 via browser templates completed by GMR user 2600. The 

FIG. 27 fiirther illustrates how the capabilities of the RFQ may include such information as a project identifier, 

present system are used by a bidding fabricator in evaluating narrative description, quantity requirements, schedule 

an RFQ. GMR graphics server 2710 (e.g., GMR server requirements* delivery requirements, and the like. The RFQ 

system 1000, FIG. 20) provides for manufacturing vendor may include information pertaining to how many ''rounds" 

engineer and craftsmen (2770) to view the stored part design 50 of bids will be con^dered, or as to whether a given round is 

model and associated features via, in the preferred a so-called "best and final" offer round. The RFQ may 

embodiment, a Java™-enhanoed browser (block 2760). include information identifying the bidding pool. When the 

Using the aforementioned CAD capabilities, vendor engj- second (GMR) and third (ETQ aspects of the invention are 

neeis and craftsman 2770 can examine the part design model integrated, the RFQ form may include a listing of the 

according to various views. As depicted by block 2750, the ss qualified fabricators identified by a search. Prime contractor 

preferred embodiment utilizes a Java™ 3D version of the GMR user 2600 may then select from the list so that the RFQ 

part design model supporting manipulation and rotation, is directed to the selected fabricators. The RFQ may include 

pans, zooms and fly-throughs. Manipulation may comprise information identifying the date and time for the bidding 

a request to view the part design model in a higher fidelity round(s), such as indicating the bidding window begins at 

representation. As depicted by blocks 2740 and 2720, 60 8:00 a.m. on November 7 and ending at 4:30 p.m. on 

graphical entities of the part design model may have links to November 14. The RFQ may also include information 

specification data, standards and materials data sheets. Fur- identifying that period when the part design model (and 

ther regarding blodc 2720, and as previously discussed in associated) data will be available and/or when GMR user 

connection with multimedia communications processing 2600 will be available for conducting muhimedia commu- 

module 978 (FIG. 13) and CAD processing module 932 65 nications sessions to discuss issues. 

(FIG. 12), so-called "markups" can be attached to the part As previously mentioned, the bidder may, and usually 

design model to facilitate discussu)ns with the prime con- will, view and examine a graphical representation of the part 
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design model (and associated technical documents or data) parts of its business, such as product planning, parts 

before submitting a bid. The bidder may also engage in a purchasing, inventory management, interaction with 

multimedia communications session with the soliciting suppliers, customer service and onier tracking. By providing 

entity to resolve any technical or business issues. A bidder a fabricator^ (or other supplier) a secure connection (or 

may also view the bidding pool list, previously described, in 5 so-caUed "portal") to the prime contractor's ERP system, the 

Older to evaluate the current slate of the bidding process for fabricator is further mtegrated wiOi the prime contractor and 

the RFQ before submitting or updating a previously- busmess boundanes are further diminished. CommerciaUy 

submitted bid. available ERP applications are available from PeopleSoft, 

Bids that ai^ submitted to the OMR provider (e.g., GMR SAP, Oracle, and Baan. 

server system 1000, FIG. 20) are posted, along with any lO Other embodiments and uses of this invention will be 

supplemental information provided by bidders. This supple- aPP^^ent to those having ordinary skill in the art upon 

mental information could provide further information about consideration of the specification and pracuce of the mven- 

the bidder or qualifying or clarifying the bid. For example, disclosed herein. The specification and examples given 

the bidder migbt say "Our bid is slighdy higher than others should be considered exemplary only, and it is contemplated 

because XYZ Machine and Tool, Inc. pays its operators a i5 appended claims will cover any other such emlwdi- 

higher wage so as to retain the highest quality personnel" or ments or modificaUons as faU withm die true scope of the 

other such information to be evaluated by the issuer of the mventioii. 

RFQ. This bid and supplemental infomaation may be stored What is claiined is: - 

by the GMR provider at a location in database UOO (HO. I- ^ server-based system for a fabricator evaluatmg 

22), such as in fabricator account data module 3850. 20 ^^^^""^ manufacturing instructions contained within a 

Generally, GMR server system 1000 may tag the bids with request for a propsal to view a part design model, compns- 
time-stamp data and data identifying the prime contractor to 

which the bid is directed. After evaluating the bids, a GMR a memory for storing a part design model provided by a 

user selects the vendor(s) best meeting the RFP designer seeking a proposal for manufacturing the part 

requirements, and winning bidders are notified. 25 represented by the part design model, said memory 

Once the bidding window is closed, the issuer of the resident at a first location, said designer resident at a 

RFP/RFQ evaluates the bids and supplemental information. secorid location and said fabricator resident at a third 

Vendors selected for contract negotiation and contract award location, where the first location is separate from both 

are notified as a process of contract formalization com- second and third locations; and 

menoes. A collection of standard clauses are stored in a 30 a server system for enabling a fabricator connected over 

database at one of the NICECAD/GMR provider's servers. a packet-switched network to access said part design 

These clauses outline the responsibilities of each party with model; 

respect to common aspects of parts procurement. An said server system having a software component for 

example might be the specific assignment of responsibility presenting the part design model to the fabricator 

for part inspection and verification. A clause may be pro- 35 through said network using a graphical user interface 

vided that assigns this re^onsibility to the fabricator or to and vdiere said software component is resident at said 

the prime contractor depending on the outcome of contract server system and accessible by said software compo- 

negotiations. Since many similar situations exist in this type nent includes a substantially planform indenpendent 

of buying, standard clauses may be used as bases for the client side application to be run on the system of the 

formal contract. Such standard contract clauses serve as 40 fabricator, where said application permits the manipu- 

starting points for negotiation. Through the virtual lation of the part design model, 

environment, these contract clauses are modified and 2. The server-based system of claim 1, wherein said 

included in a "formalized** contract that is custom tailored manipulation comprises one or more of rotation, translation, 

for the specific manufacturing job. A formalized contract two-dimensional cutting and a fly-through, 

may be thought of as a "signable" contract that has resulted 45 3. The server-based system of claim 1, wherein the part 

from negotiations ovet a set of ''standard" starting points. design model comprises a plurality of three-dimensional 

This feature is necessary to accommodate the very dynamic graphical features which are linked by the server system 

nature of Uus type of procurement. with at least one of specifications, reguktions and standards 

Hie terms and conditions negotiations may use the secure associated with each of the plurality of features, 

multimedia communications capability previously 50 4. The server-based system of claim 3, wherein said 

discussed, whereby a prime contractor and successful bidder software component further provides for the fabricator to 

can engage in negotiations using the quasi- teal-time video select a specific three-dimensional graphical feature in order 

and/or audio. Stored standard form contracts (see, e.g., to view die at least one associated deification, regulations 

module 696, FIG. 6) and stored standard terms and oondi- and standard associated with the selected feature, 

tions (see, e.g., module 697, FIG. 6) may be employed. The 55 5. The server based system of claim 4, wherein the 

digital signature capability provides a means for both parties selection is performed using a mouse device, 

to formalize agreements once they are negotiated (sec, e.g., 6. The server-based system of claim 1, wherein said server 

module 699, FIG. 6). Once negotiated and formalized, system is fiirther adapted to permit the designer to review the 

contracts may be stored by the GMR provider, such as at accuracy of detailed manufacturing instructions contained 

module 415 of FIG. 4. 60 within said request for a proposal. 

A final aspect to the present invention is that the provider 7. The server based system of claim 1, wherein said 

the GMR provider (e.g, GMR server system 1000) may software component further enables the fabricator and the 

further provide to the winning fabricator(s) a network-based designer to engage in a oonununications session that is 

connection to the prime contractor's Enterprise Resource substantially real-time. 

Planning (ERP) system. ERP generally refers to a multi- 65 8. The server based system of claim 7, wherein said 

module software application integrated with a relational communications session comprises one or more of audio and 

database used by a prime contractor to manage important video. 
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9. The server based system of claim 7, wherein said 23. The server-based system of claim 22, wherein said 
commimicatioDS session comprises the simultaneous pie- communications session comprises one or more of audio and 
scntation of the part design model to the fabricator and the video. 

designer. 24. The server-based system of claim 22, communications 

10. The server based system of claim 9, wherein the 5 session comprises the simultaneous presentation of the part 
simultaneous presentation includes the manipulation of the design model to the fabricator and the designer. 

part design model. 25. The server-based system of claim 22^ wherein the 

U. The server-based system of claim 4, wherein the at simultaneous presentation includes the manipulation of the 

least one associated specifications, regulations and standrds manipulation of the part design model, 

reside in the server memory and are sent over the netwoiic 10 26. A process for obtaining information for a fabricators 

coimection to the client-side on demand. registry comprising the steps of: 

12. The server-based system of claim 6, wbeiein the part providing one or more fabricator manager applications to 
design model comprises a plurality of three-dimensional ^ne fabricator, where the one or more fabricator 
graphical features which are linked by the server system manager applications: 

with at least one specification, regulation and standard 15 j^ast one fabricator in managing the 

associated with each feature. fabricator 'business; 

13. Ihe server based system of claim 1, wherein said 2) reside in a central repository; and 
software component further provides for the fabricator to 3V ^ kccess^d through a global open network. 
select a specific three-dimensional^graphical feat™ in order ^^^^ fabricator, where the 

T± ^ated specification, icgulaUon 20 data iJthe result of the at least one fabricator using the 

. J . f,. . , one or more fabricator manager applications; 

14. The server-based system of claim 13, wherem the at . , . j j . ^ . . . 
least one associated specification, regulation and standard aggregaUng the received daU into a fabricator registry; 
reside in the server memory and are sent over the network 

connection to the client-side application on demand. 25 providing access to the fabricator registry to at least one 

15. A server-based system for a fabricator evaluating designer, where at least one of: 

detailed manufacturing instructions to view a part design the at least one designer accesses at least a portion of 

model, comprising: the received data in the fabricator registry; and 

a memory for storing part design model provided by a the entiry providing the fabricator manager aj^hca- 

designer where a part is represented by the part design 30 accesses at least a portion of the received data 

model, wherein the part design model comprises at ^ «>"«^ providing services to one or more 

least one three-dimeosional graphical depiction having customers. 

a plurality of features whidi are linked by the server 27. The process according to claim 26, where the one or 

system with at least one specification, regulation, and fabncator apphcaUons comprises a too mventory 

standard associated with each of the plurahty of fea- 35 appHcation, where the fabncator uses the tool mventory 

mres; and a server system for enabling a fabricator application to maintain a catalog of standard and custom 

connected over a packet-switched network to access the fabricator, 

said part design model: 28. The process according to claim 26, where the one or 

said server system having a software component for more fabricator apphcations comprises a 

presenting the part design model to the fabricator 40 scheduhng application where the fabncator uses the 

through said network using a graphical user interface. availabihty scheduhng application to mamt^un a 

wherdn said software component further provides for ^^ff^ mdicaUng jobs one or more machines are sched- 

the fabricator to select a specific feature of the three- f^^ ^^^^^^^^ 

dimensional graphical depiction in order to view the _^ "J^J^^ 1 • . ^ 

specification, regulation, and standard associated with 45 29. The process accordmg to claim 26, where the one or 

the selected feaUire fabncator apphcations comprises a machme mamte- 

16. Hie setver-bascd system of daim 15. wherein said scheduling appUcation. where the one or more fabri- 
sofiwaR component further permits the manipulation of the "'"^ maintenaDce schedulmg apphcaUon 
nart desien model ^ mamtam a schedule mdicating when one or more 

-nn 'TiT Lj * ri'ifu* -j^^ machines are scheduled for maintenance and when each of 

17. The serv^er-based system of claim 15, wherem said so ovuvum^ m lu ^u«iu u u 

manipulationcomprisesoneormoreofrotation,translation, "ad mamtenance 

two^mensional cutting and a fly-through. ^0. The process acc»rdmg to claim 26. where the one or 

18. -me server4)ased system of daim 15. wherein the """'i? f^bncat^r applications comprises an accounting 
selecdon is performed using a mouse device. apphcation, where the fabricator uses the acoouDtmg apph- 

19. Hk server-based system of claim 15. wherein said SS |° °>'""'»^ mfonnation, transaction records, 
server system is further adapted to permit the designer to records. , 

review L accuracy of detailed manufacturing instructions ^l. Tie process a«x>tdmg to daun 26. where the one or 

contained within s^d request for a proposal. f*''"^'^"' apphcations comprises a trammg inanage- 

20. nie server-based system of daim 15. wherein said apphcation where the febricator uses the training 
proposal includes at least a portion of the part design model. 60 ■»»°agf"?e'>t «PPli«.tion to mamtain at least one record of 

21. THe server-based system of daim 15, wherein said ^^^^ "^"^ °^ ""^."^ .'""Ployf • ^ . . 
part design model was stored in said memory at a time ^2. The process accordmg U. cUmi 31, where the traimng 
before silmission of said proposal. of the one or more employees mdudes at least one of: 

22. The server-based system of daim 15, wherein said certifications received by the one or more employees; 
software component further enables the fabricator and the 65 b) the most recent training of the one or more employees; 
designer to engage in a communications session that is c) the next scheduled training for the one or more employ- 
substantially real-time. ees; 
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d) the years of experience of the one or more employees; a schedule indication jobs one or more machines are sched- 
and uled for and when the one or more machines are available 

e) the machines the one or more employees are trained on. for a new job. 

33. The process according to claim 26, where the one or 38. The system according to claim 35, where the one or 
more fabricator applications comprises a certification man- ^ more fabricator applications comprises a machine mainte- 
agpment application, where the fabrication uses the certifi- nance scheduling application, where the fabricator module 
cation management application to maintain at least one uses the machine maintenance scheduling application to 
record of the certification status of the fabricator, and to maintain a schedule indicating when one or more machines 
track the compliance status of the fabricator for one or more are scheduled for maintenance and when each of the one or 
certifications. more machines last had maintenance. 

34. The process according to claim 26, further comprising 39. The system according to claim 35, where the one or 
thcstepof receiving a selection of one or more of the at least more fabricator applications comprises an accounting 
one fabricator by the at least one designer based on the application, where the fabricator module uses the accounting 
accessed data. application to maintain billing information, transaction 

35. A system for obtaining information for a fabricators ^5 records, and billing records. 

registry comprising: 40. The system according to claim 35, where the one or 

. at least one fabricator module; more fabricator applications comprises a training manage- 

^. ment application, where the fabricator module uses the 

an application provider module for providmg one or more _ . . ' i - . ... * i * 

eKl'. 1- f *^ training management application to mamtaio at least one 

fabncator manager applicauons to the at least one r *u f • - * . c i 

fabricator module, whL the one or more fabricator "^^^^^^ f status of one or more empbyees. 

manager appUcations assist the at least one fiibricator ^ The system according to claim 35, where the training 

module in Lnaging the fabricator-business, data is staUis of the one or more employees mcludcs at least one of : 

inputby the at least one fabricator module using the one a) certifications received by the one or more employees; 

or more fabricator manager applications, and the data is ^5 b) the most recent training of the one or more employees; 

aggregated into a fabricator registry; and c) the next scheduled training for the one or more employ- 

at least one designer module, where at least one portion ees; 

of: d) the years of experience of the one or more employees; 

a) the at least one designer module accesses a portion of and 

the data in the fabricator registry; and 30 e) the machines the one or more employees are trained on. 

b) the entiry providing the fabricator manage application 42. The system according to claim 35, where the one or 
accesses at least a portion of the received data in the more fabricator applications comprises a certification man- 
course of providing services to one or more customers. agement application, where the fabricator module uses the 

36. The system according to claim 35, where the one or certification management application to maintain at least one 
more fabricator applications comprises a tool inventory record of the certification status of the fabricator module, 
ai^licatioa where the fabricator module uses the tool inven- and to track the compliance status of the fabricator for one 
tory application to maintain a catalog of standard and or more certifications. 

custom tools used by the fabricator module. 43. The system according to claim 35, where the at least 

37. Hie system according to claim 35, where the one or one designer module selects one or more of the fabricator 
more fabricator applications comprises a machine availabil- ^ modules based on the accessed data. 

ity scheduling application, where the fabricator module uses 

the machine availability scheduling application to maintain * * « * « 
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ABSTRACT 



A market making node in a network routes machine readable 
documents to connect businesses with customers, stq>pliers 
and trading partners. The self defining electronic documents, 
such as XML based documents, can be easily understood 
amongst the partners. Definitions of these electronic busi- 
ness documents, called business interface definitions^ are 
posted on the Internet, or otherwise communicated to mem- 
bers of the network. The business interface definitions tell 
potential trading partners the services the company offers 
and the documents to use when communicating with sudi 
services. Thus, a typical business interface definition allows 
a customer to place an order by submitting a purchase order 
or a supplier checks availability by downloading an inven- 
tory status report. Also, the registration at a market maker 
node of a specification of the input and output documents, 
coupled with interpretation information in a common busi- 
ness library, enables participants in a trading partner network 
to execute the transaction in a way which closely parallels 
the way in which paper based businesses operate. 
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MARKET MAKERS USING DOCUMENTS based on CORBA HOP (Common Object Request Broker 

FOR COMMERCE IN TRADING PARTNER Architecture Internet ORB ProlocolX are being pursued. Use 

NETWORKS of the common distributed object model is intended to 

simplify the migration of enteiprise systems to systems 

CROSS-REFERENCE TO RELATED 5 ^hich can intcr-operate at the business appUcation level for 

APPLICAnONS electronic commerce. However, a consumer or business 

The present application is related to co-pending U.S. ^ing one framework is unable to execute transactions on a 

patent application Ser. No. 09/173358, filed on Oct 16, different framework. This limits the growth of electronic 

1998, the same day as the present application, and having the commerce systems. 

same inventors, entitled DOCUMENTS FOR COMMERCE Companies implementing one framework will have an 

IN TRADING PARTNER NETWORKS AND INTER- application programming interface API which is different 

FACE DEFINITIONS BASED ON THE DOCUMENTS; than the APPs supporting other frameworks. Thus, it is very 

and to co-pending U.S. patent application Ser. No. 09/173, di£Gcult for companies to access each others business 

847, filed on Oct. 16, 1998, the same day as the present services, without requiring adoption of common business 

application, and having the same inventors, entitled PAR- system interfaces. The development of such busii^ss system 

TICIPANT SERVER WHICH PROCESSES DOCU- interfaces at the API level requires significant cooperation 

MENTS FOR COMMERCE IN TRADING PARTNER amongst the parties whidi is often impractical. 

NETWORKS. Accordingly, it is desirable to provide a framework which 

COPYRIGHT NOTICE facilitates interaction amongst diverse platforms in a com- 

munication network. Such system should facilitate sponta- 

A portion of the disclosure of this patent document neous commerce between trading partners without custom 

contains material which is subject to copyright protection. integration or prior agreement on industry wide standards. 

The copyright owner has no objection to the facsimile Further, such systems should encourage incremental path to 

reproduction by anyone of the patent document or the patent business automation, to eliminate much of the time, cost and 

disclosure as it appears in the Patent and Trademaric Office ^ risks of traditional systems integration 

patent file or records, but otherwise reserves aU copyright OveraU. it is desirable to provide an ekctronic commerce 

rights whatsoever. system that replaces the closed trading partner networks 

BACKGROUND OF THE INVENTION based on proprietary standards with open maricets. 

1. Field of the Invention 30 SUMMARY OF THE INVENTION 

The present invention relates to systems and protocols r^. « 

. ,. ^ ij. The present mvention offers an infrastructure for connect- 

supportmg transactions among diverse clients coupled to a • . • . i* j ^ 

f *^ , , 1 1 * * J * 1 mg busmesses with customers, suppuers and tradmg part- 
network; and more particularly to systems and protocols ^ „ j • r ^ ^ r ^ • 1- 
<.»«^r.iPt^» t^r^^^^r.^ ^u*f^^ ^^^^^ thc uifrastructure of the present invention, 
supportmg commercial transactions among platforms liav> . - r ^ - ir 
. . * . ^ * *^ 35 compames exchange mfonnation and services using self- 
mg vanant architectures. j c • u- j 1.1 -1 * u v»irT 

® ... - defining, machine-readable documents, such as XML 

2. Descnplion of Related Art (Extensible Markup Unguage) based documents, that can 
The Internet and other communications networks provide be easily understood amongst the partners. Documents 

avenues for communication among people and computer which describe the documents to be exchanged, called 

platforms which are being used for a wide variety of ^ business interface definitions BIDs herein, are posted on the 

Uransactions, including commercial transactions in which Internet, or otherwise communicated to members of the 

participants buy and sell goods and services. Many efforts network. The business interface definitions tell potential 

are underway to facilitate commercial transactions on the trading partners the services the company offers and the 

Internet. However, with many competing standards, in order documents to use when communicating with such services, 

to execute a transaction, the parties to the transaction must ^5 jhus, a typical business interface definition allows a cus- 

agree in advance on the protocols to be utilized, and often tomer to place an order by submitting a purchase order, 

require custom integration of the platform architectures to compliant with a document definition published in the BID 

support such transactions. Commercial processes internal to of a party to receive the purchase order. A supplier is allowed 

a particular node not compatible with agreed upon to check availability by downloading an inventory status 

standards, may require substantial reworif for integration report compliant with a document definition published in the 

with other nodes. Furthermore, as a company commits to BID of a business system managing inventory data. Use of 

one standard or the other, the company becomes locked-in to precfcfined, machine-readable business documents provides 

a given standardized group of transacting parties, to the a more intuitive and flexible way to access enterprise 

exclusion of others. applications. 

A good overview of the challenges met by Internet 55 a node in the commerce network establishes an interface 

commerce development is provided in Teoenbaum, et al., for transactions according to thc present invention that 

**Eco System: An Internet Commerce Architecture", comprises a machine-readable ^ccification of an interface. 

Computer, May 1997, pp. 48-55. along with a machine-readable data structure that includes 

To open commerdal transactions on the Internet, stan- interpretation information for the machine-readable specifi- 

dardization of architectural frameworks is desired. Platforms 60 cation of the interface. The machine-readable specification 

devetoped to support such commercial frameworks include of the interface includes a definition of an input document 

IBM Commerce Point, Microsoft Internet Commerce and a definition of an output document, that are accepted and 

Framework, Netscape ONE (Open Network Environment), produced by transaction processes for which the node acts as 

Oracle NCA (Network Computing Architecture), and Sun/ an interface. The definitions of the input and output docu- 

JAVASoft JECF (JAVA Electronic Commerce Framework). 55 ments comprise respective descriptions of sets of storage 

In addition to these proprietary frameworks, program- units and logical structures for sets of storage units^ such as 

ming techniques, such as common distributed object model according to a standard XML based document. The 
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machioe-Feadable data structure that includes interpretatioo least part of the definition of the output document of the 

information according to various aspects of the invention complementary interface in the definition of the input docu- 

includes data type specifications (e.g. string, array, etc.) for meat of the interface stored in the specification, 

logical structures in the definitions of the input and output establishing the stored specification of an 

docimients, content models (e.g. lists of possible value^^ 5 ^^^^^^^ according to another aspect of the invention 

logical stnictures and/or data structures that map predefined ^^^^^^ ^^^^ ^^^^^^^ machine-readable sped- 

sets of storage units for a particu ar logic structure to ^ ^ repository. THe repository stores a Ubrwy of 

respective entnes in a list in order to provide a semantic , . . ^ ; j i j i_ * 

definition of logical structures (e.g. mapping codes to prod- ^^i^ structures, content inodels, and schematic maps for 

uct names^ \ o rr o r i^gjp structures, and defimtion of documents that comprise 

J' ^, . r.i. . ^. . * _c logic structures used to build interface description. A reposi- 

Aocordmg to other aspects of the mvenUon, the interface ^ ^^^^^ ^ ^^^^ 

mchides a repositoiy m memory accessible by at east one J^^^ descriptions which can be easily shared. Any 

node m the network that stores a hbrary of logic structures * *jr 

J . . . r r .1. 1 ♦ . *- diffcrcnces between the mput document created for a par- 

and mlerpretatioo information for the logic structures. The ^. , j .u * * j * . j f. 

. ^ . i-c ticular process and the output document expected as a return 

repository can l^^ttnded to mclude a hT,rary.of^^ ^ complementary pro«ss can be eas^ negotiated by 

of mput and output documents, a libraiy of specifications of ^^^^^^^^^^^ the network and agreetag on common 

m erfaces. and a library of specifications for participant , ^^^^^^ ,^ ^ i,rformation. 

interface nodes m the network. -■. ■ - , ■ • , •. •• ,■ ■ -•- 

Tlius, a participant in the transaction fiamework of the Th« machine-readable spccificaUon of an interface of a 

present invention executes transactions amongst nodes in a ^ according to one aspert of the mvention mcludes 

network that inchides a phirality of nodes executing pro- » «^°«"°'f f'nipliant with a definition of an mterfa« 

cesses involved in the trMisactions. The method includes that is shared amongst members of the network, 

storing a machine-readable specification of an interface tox ^ °^ ""^^ff document mcludes logic struc- 

a transaction, the spedfication includes a defimtion of an '"'f stonng an identifier of a particular tranMcUon and 

inptu document and a definition of an output document The 25 °^ definitions and references to defimtions of 

defimtion of the input and output documents comprise .'^^ «J"P"1 dooimenu for the parUcu^ar transaction, 

respective descriptiois of sets of storage units and logical That js. the mteiface descnption for a particular service may 

strucniresforthesetsofstorageunits.Inaprefeiredsystem. enrompass a definition of the mput and output 

the definitions are expressed in a manner compliant with a docu-nents. Alternatively, it may mcludc pomteis to a loca- 

standaid XMLdocument type defimtion DTD, extended by 30 '"•'^ lepository. or elsewhere in the network, of such 

semantic mapping, content modeling and data typing of * 

some elements. The participant in the transaction receives According to another alternative of the invention, the 

data comprising a document through a communication net- machine-readable ^edfication includes a business interface 

work. The participant parses the document according to the definition BID document compliant with a definition of an 

specification stored for a transaction to identify an input 35 interface document that inchides logical structures for stor- 

document for the transaction. After parsing the document, at i°g *° identifier of the interface, and for storing at least one 

least a portion of the input document is provided in a of specifications and referwices to specifications of a set of 

machine-readable format to a transaction process which ^ne or more transactions supported by the interface. For 

produces an output. An output document is formed com- eac^ supported transaction, the document includes at least 

prising the output of the transaction process, based on the 40 definitions and references to definitions of input and 

definition of an output document in the stored specification. ^^tp"^ documents for the particular transaction. 

The output document is transmitted on the communication According to another aspect of the invention, the storage 

network, typically back to the source of the input document, units defined in the definitions of the input and output 

or elsewhere as suits the needs of a particular type of document comprise parsed data including character data 

transaction. 45 encoding text characters, and mark-up data identifying sets 

Thus the business interface definition bridges the gap of storage units according to the logical stmctures of the 

between the documents specified for example according to input and output documents. According to another aspect of 

XML and the programs which execute on the front end of the the invention, at least one of the sets of storage units encodes 

transaction processing services at particular nodes. Such the plurality of text characters providing a natural language 

front ends are implemented for example by JAVA virtual 50 ^0^^. This facilitates the use of the definitions of input and 

machines, or by other common architectures providing for output documents by human readers and developers of such 

intercotmection of systems across a network. Hie business documents. 

interface definition provides a technique by whidi a trans- According to another aspect of the invention, the speci- 
action protocol is programmed using the business interface fication of the input and ou^ut documents includes inter- 
definition document The program for the protocol of the 55 pretation information for at least one of the sets of storage 
transaction is established by a detailed formal specification units identified by the logical structure. The interpretation 
of a document type. information in one example encodes definitions for sets of 
Themachine-readablespedficationof the interface of the parsed characters. In another example, the interpretation 
transaction is made accessible to other pktforms in the information provides for content model specifications, such 
network. Participant platforms include resources to design 60 as reqmring a specific logic structure to carry a member of 
input documents and output documents according to the a list of codes mapped to product descriptions in a catalog, 
transaction interface specified at a complementary node. In some systems, the storage units in a logic structure of a 
Thxis, participant nodes include resources to access the document may include sets of unpaised data, as suits the 
definition of an input document for the complementary needs of a particular implementation, 
interface and a definition of an output document for the 65 According to yet another aspect of the invention, the 
complementary interface. The stored specification for the transaction process in a particular platform has a transaction 
accessing participant node is established by inchiding at prooessingarchitecture^^iichisoneof a plurality of variant 
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transaction processing architectures. Thus the participant of the transaction processes into sets of storage units and 
node includes resources for translating at least a portion of logical structures of the output document, 
the input document into a format readable according to the The tools to build a definition of a participant interface in 
variant transaction processing architecture of the transaction a preferred system include instructions executable by the 
process utilizing the information. The elements of the docu- 5 system to access elements of the definition from comple- 
ment definition are translated into programming objects that mentary nodes and/or from a repository that stores a library 
include variables and methods according to the variant of logical structures and interpretation information for logi- 
transaction processing architectures of the transaction pro- cal structures used to build interface descriptions. According 
cess. For a participant having a JAVA virtual machine acting to various aspects of the invention, the repository includes 
as a transaction process front end, particular fields in the not only a library of logical structures but definitions of 
documents are translated into JAVA objects, including the documents that comprise logical structures, and formats for 
data as well as get and set functions assodated with a JAVA specifying participant interfaces. According to this aspect of 
object. Other transaction processing architectures support- the invention, tools are provided for building specifications 
able according to the present invention include processes of business interfaces according to the techniques described 
compliant with an interface description language in the above in connection with the description of the participant 
sense of Common Object Request Broker Architecture nodes. The tools for building interfaces and the tools for 
CORBA, Component Object Model COM, On-Line Trans- compiling the interfaces into resources needed for commu- 
action Processing OLTP, and Electronic ,Data . Interchange . . nication with transaction processing architectures according 
HDL to this aspect of the invention, are implemented in partici- 

Aocording to other aspects of the invention, a repository 20 nodes in the preferred system, and utilized for the 

is provided that stores document types for use in the plurality development and optimization of the interface descriptions 

of transactions. The machine-readable q>ecification for a as use of the network grows based on interface descriptions 

particular transaction defines at least one of the input and that define input and output documents, 

ou^ut documents by reference to a document type in the Accordingly, another aspect of the invention provides an 

repository. According to another aspect, the dociiment type 25 apparatus that includes memory and a data processor that 

included in the repository include a document type foi executes instructions stored in the memory that include tools 

identifying participants in the network. Such document type to build a definition of a participant interface and a compiler 

providing structures for identifying a participant, specifying performing the functions described above, 

the services supported by the participant, and specifying the According to yet another aspect of the invention, the use 

input and output documents for each of such services. 30 of the participant interface descriptions enables the opera- 

lo addition to the methods described above, the present tion of a market maker node. At such a node, a method for 

invention provides an apparatus for managing transactions managing transactions is provided that comprises storing 

among nodes that includes a network interface, memory for machine-readable specifications of a plurality of participant 

storing data and programs of instructions including a interfaces v^diich identify transactions supported by the 

machine -readable specification of an interface for a trans- 35 interfaces, and the respective input and output documents of 

action as described above, and a data processor that is such transactions. As described above, the definitions of the 

coupled with the memory and the network interface. The input and output documents comprise respective descrip- 

programs of instructions stored in the apparatus include tions of sets of storage units and logical structures for the 

. logic to execute the processes described above for a partici- sets of storage units, such as according to the XML standard, 

pant in the transactions. 40 In addition, the definitions of the transactions and the 

The present invention further provides an apparatus for definitions of the participant interfaces all comprise docu- 
establishing participant interfaces for transactions executed ments specified according to a technique compliant with 
on a system that include a network interface and a data XML or other standardized document expression language, 
processing resources that execute transaction processes At such market maker node, data comprising a document is 
according to a transaction processing architecture. The appa- 4S received over a communication network. The document is 
ratus includes programs of instructions that are executable parsed according to the specifications to identify an input 
by the system and stored on a medium accessible by the document in one or more transactions which accept the 
system that provide tools to build a definition of a participant identified input document At least a portion of the input 
interface for a participant in a particular transaction. The document is provided in a machine-readable format to a 
definition of a participant interface includes a definition of so transaction process associated with the one or more identi- 
an input document and a definition of an output document. fied transactions. The step of providing at least a portion of 
The definitions of the input and output documents comprise the input document to a transaction process includes execut- 
respective machine-readable descriptions of sets of storage ing a routing process according to a processing architecture 
imits in Ic^cal structures for the sets of storage units, which at the market maker node. The routing process in one aspect 
may be compliant in one aspect of the invention with XML S5 of the invention is executed according to a particular pro- 
document type definitions. cessing architecture, and at least a portion of the incoming 

The apparatus for establishing participant interfaces document is translated into the format of the processing 
according to this aspect of the invention also includes architecture of the routing process. The translating accord- 
programs of instructions stored on a medium accessible by ing to the preferred aspect includes producing programming 
the data processing system and responsive to the definitions 60 objects that include variables and methods according to the 
of input and output documents to compile data structures processing architecmre of the routing process, 
correspondiog to the sets of storagp units and logical struc- According to another aspect of the invention, the market 
tures of the input and output documents that are compliant maker node also supports the repository structure. Thus, a 
with the transaction processing architecture, to compile process is included at the market maker node for allowing 
instructions executable by the system to translate the input 65 access by participants in the network to a repository stored 
document to the corresponding data stmcturcs^ and to com- at the market maker node. As described above, the reposi- 
pile instructions executable by the system to translate output tory includes definitions of logic structures, interpretation 
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information, and document definitions for use by the par- create a trading community. The server operates to parse the 

ticipant nodes to build transaction interface documents and incoming documents and invoke the appropriate services, 

includes instances of business interface definitions that Also the server according to the present invention handles 

identify the participants, and the transactions executed by the translation tasks from the format of the documents being 

the respective participants. 5 received and transmitted, to and from the formats of the 

The routing process includes according to various alter- respective host systems. Thus, trading partners need only 

natives the translating of the input document into the variant structure, content and sequencing of the busi- 

piocessing architecUire of the processes to whidi the docu- °ess documents exchanged, and not on the details of appli- 

ment is to be routed, or routing the input document in its cation prog^^ammer interfaces. How a document is processed 

origiaal document fonnat across the network to a remote 10 and the actions which result from receipt of a document are 

processing node, or to combinations of such processes. In strictly up to the businesses providing the services. This 

alternatives, the routing process may also include techniques elevates integration frona the system level to the business 

for transforming an input document defined according to one ^yd. It enables the business to present a clean and stable 

input document definition into a different document defined interface to its partners despite changes in its internal 

according to a different document specification for a process 15 technology implementation, organization or processes, 

which has registered to watch for the input document. The whole process of building business interface defini- 

Also, the market maker node is provided according to the enabling servers to manage commerce according 
present invention as aj^aratus that includes a network '" ' to' siibh desciiptions is facilitaled by" a common business 

interface, memory storing daU and programs of instructions library, or repository, of information models for generic 

including the specifications of the participant interfaces, and business concepts including business description primitives 

a data processor. The logic is provided with the data pro- companies, services and products, business forms like 

cessor in the form of programs of instructions or otherwise catalogs, purchase orders and invoices, and standard 

to perform the market maker process as discussed above. measurements, including time and date, location and clas- 

Accordingly, the present invention provides a foundation sification of goods, 

for electronic commerce based on the sharing of specifica- Other aspects of the present mvention can be seen upon 

tions of input and output documents. Documents provide an review of the figures, the detailed description, and the claims 

intuitive and flexible way to access business services^ much which follow. 

simpler to implement than programming APIs. It is much BRIEF DESCRIPTION OF THE FIGURES 
easier to interconnect companies in terms of documents that 

are exchanged, on which such companies akeady largely FIG. 1 is a simplified diagram of an electronic commerce 

agree, than in terms of business system interfaces which network including business interface definitions BIDs 

invariably differ. In addition, such documents are specified according to the present invention. 

in a human readable format in the preferred embodiment. FIG. 2 is a simplified diagram of a business interface 

According to the present invention the business interfaces 35 definition document according to the present invention, 

arc specified in documents, such as XML documents that are EIG. 3 is a conceptual block diagram of a server for a 

readily interpretable by humans as well as by computers. participant node in the network of the present invention. 

Utilizationof the document based transaction architecture FIG, 4 is a flow chart illustrating the processing of a 

of the present invention involves the use of a parser which received document at a participant node according to the 

operates in basically the same way for any source of 40 present invention, 

documents, eliminating much of the need for custom pro- FIG. 5 is a block diagram of a parser and transaction 

grams to extract and integrate information from each par- process firont end for an XML based system, 

ticipant in the network. Thus, integrating enterprise infor- piQ, 5 a conceptual diagram of die flow of a parse 

mation from accounting, purchasing, manufacturing, function. 

shipping and other functions can be accomplished by first 45 FIG. 7 is a simplified diagram of the resources at a server 

convertmg each source to a document having an architecture ^ for building a business interface definition according to 

accordmg to the present mvenUon, and then processing the invention. 

parsed data stream. Each node in the system that participates » ■ ■ j r .■ 

to the maricet only needs to know about the fomiat of its RG. 8 is a simphfied diagram of a repository according 

totemal systems, as well as the format of the documents 50 f ^he Present mvention for use for building busmess inter- 

being specified for interchange according to the transaction. ^ 

Thus, there is no need to be able to produce the native format HG. 9 is a flow chart Qlustrating the processes of bmlding 

of every other node which might want to participate in the ^ busmess mterface defimtion according to the present 

electronic commerce network. invention. 

For complete business integration, the present invention 55 . FIG. 10 provides a heuristic view of a repository accord- 
provides a repository of standardized logical structures, like "^S P"^^"^ mvention. 

XML elements, attributes or meta data, establishing a FIG 11 is a simplified diagram of the resources at a server 

semantic language for particular commerce communities, a providing the market maker function for the network of the 

means for mapping between different meta data present invention based on business interface definitions, 

descriptiois, and a server for processing the documents and 60 FIG. 12 is a flow chart for the market maker node 

invoking appropriate applications and services. The basic processing of a received document, 

building blocks of a network according to the present FIG. 13 is a flow diart illustrating the process of regis- 

invention include the business interface definitions which tering participants at a market maker node according to the 

tell potential trading partners what online services a com- present invention. 

pany offers and which documents to use to invoke the 6S FIG. 14 is a flow chart illustrating the process of provid- 

services; and servers which provide the bridge to bind ing service specifications at a market maker node according 

together the set of internal and external business services to to the process of FIG. 9. 
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FIG. 15 is a diagram illustrating the sequence of operation For each transaction in the service set, an interface definition 

at a participant or market maker node according to the is provided, including the transaction BID 205, the transac- 

present invention. tion BID 206, and the transaction BID 207. Within each 

FIG. 16 is a conceptual diagram of the elements of a transaction BID, such as transaction BID 205, logical struc- 

commercial network based on BIDs, according to the 5 tures are provided for including a name 208, a lo<^U^^ 

present invention. ^^5*1 ^^^^^ is performed 209, the 

operations performed by the service 210, and a set of input 

DETAILED DESCRIPTION documents indicated by the tag 211. Also, the service BID 

, J ^ , . , ^ 205 includes a set of output documents indicated by the tag 

Adetaileddescriptionof thepresentinvention 212. The set of input documents 211 includes a business 

with resp«:t to the figures, m which HG. 1 illustrates a interface definition for each input document for which the 

network of market participants and market makers based on services are designed to respond, including input document 

the use of business interface definitions, and supporting the business interface definitions 213, 214, and 215. Each busi- 

tradingofinputandoutputdocumentsspedfiedaccordingto ^ess interface definition for an input document includes a 

such interface descriptions. The network inchides a plurality Q^me 216, a location on the network at which a description 

of nodes U-18 which are interconnected through a com- the document can be found 217, and the modules to be 

mumcatioo network such as the Internet 19, or other tele- ^^^^ ^ j^c document as indicated by the field 218. In a 

cpmmunicatipns or data communications network. Each of similar manner, the output document set 212 includes inter- - 

the nodes 11-19 consists of a computer, such as a portable ^ce definitions for output documents including the output 

computer, a desktop personal computer, a workstaUon, a document BID 219, output document BID 220. and output 

network of systems, or other data processing resources. The document BID 221. For each output document BID, a name 

nodes include memory for storing the business interface 222, a location on the network or elsewhere 223, and the 

definition, processors that execute transaction processes modules of the document 224 are reified. The business 

supporting commercial transactions with other nodes in the interfece definition for the partidpaot as iUustrated in HO. 

network, and computer programs which are executed by the 2 includes actual definitions of a togic structures to be ' 

proces^rs in support of such services. In additioii each of fo^ j^put and ou^nit documents of the respective 

the nodes mdudes a networic mt^ace for providmg for services, or pointers or other references to tocations at which 

cominumcation across the Internet 19. or the other commu- ^hese definitions can be found. 

mcation network. ^j^^ preferred system, the document of FIG. 2 is 

In the environment ofFIG.l, nodes 11, 12, 13, 14, 16 and spedfied in an XML document type definition DTD, 

18 are designated market participants. Market participants although other document definition architectures could be 

include resources for consumers or suppliers of goods or ^g^d, and includes interpretation information for the logical 

services to be traded accordmg to commercial transactions structures used in interpretation of instances of the docu- 

established according to the present invention. ments. In addition, each of the transaction BIDs, input 

In this example, nodes 15 and 17 are market maker nodes. 35 document BIDs and output document BIDs are specified 

The market maker nodes include resources for registering according to an XML document type definitions. The XML 

business interface definitions, called a BID registry. Partici- type document is an example of a system based on parsed 

pants are able to send documents to a market maker node, at data that indudes mark-up data and character data. Mark-up 

which the document is identified and routed to an appropri- data identifies logical structures within the document and 

ate partidpant which has registered to receive such docu- ^ sets of character data identify the content of the logical 

ments as input. The market maker also facilitates the com- structures. In addition, unparsed data can be carried in the 

mercial networic by maintaining a repository of standard document for a variety of purposes. See for example the 

forms making up a common business library for use in spedfication of the Extensible Mark-up Language XML 1.0 

building business interface definitions. REC-XML-19980210 published by the WC3 XML Working 

In this example, the market participant 18 is connected 45 Group at WWW.W3.ORG/TR/1998/REC-XML-19980210. 

directly to the market maker 17, rather than through the Thus in an exemplary system, partidpant nodes in the 

Internet 19. This connection directly to the market maker network establish virtual enterprises by interconnecting 

illustrates that the configuration of the networks supporting business systems and services with XML encoded docu- 

commerdal transactions can be very diverse, incorporating ments that businesses accept and generate. For example, the 

public networks such as the Internet 19, and private con- 50 business interface definition of a particular service estab> 

nections such as a local area network or a Point-to-Point lisbes that if a document matching the BID of a request for 

connection as illustrated between nodes 17 and 18. Actual a catalog entry is received, then a document matching a BID 

communication netwoiks are quite diverse and suitable for of a catalog entry will be returned. Also, if a document 

use to establish commerdal transaction networks according matching the BID of a purchase order is received, and it is 

to the present invention. 55 acceptable to the receiving terminal, a document matching 

FIG. 2 is a heuristic diagram of nested stmctures in a the BID of an invoice will be returned. The nodes in the 

business interface definition BID which is established for network process the XML documents before they enter the 

market participants in the network according to the present local business system, which is established according to the 

invention. The business interface definition illustrated in variant transaction processing ardiitecture of any given 

FIG. 2 is a data structure that consists of logic structures and 60 system in the network. Thus, the system unpacks sets of 

storage tmits arranged according to a formal definition of a related documents, such as MIME-enooded sets of XML 

document structure, such as a XML document type defini- documents, parses them to create a stream of "mark-up 

tion DTD. The structure of FIG. 2 includes a first logic messages". The messages are routed to the appropriate 

structure 200 for identifying a party. Assodated with the applications and services using for example an event listener 

togic structure 200 are nested logic strucmres for carrying 6S model like that described below. 

the name 201, the physical address 202, the network address The documents exchanged between business services are 

or locatk>D 203, and a set of transactions for a service 204. encoded using an XML language built from a repository of 
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building blocks (a common business language) firom wbicb 
more complex document definitions may be created. The 
repository stores modules of interpretation information that 
are focused on the functions and information common to 
business domains, including business description primitives 
like companies, services and products; business forms like 
catalogs, purchase orders and invoices; standard 
measurements, like time, date, location; classification codes 
and the like providing interpretation information for logical 
structures in the XML documents. 

The business interface definition is a higher level docu- 
ment that acts as a schema used for designing interfaces that 
trade documents according to the present invention. Thus the 
business interface definition bridges the gap between the 
documents specified according to XML and the programs 
which execute on the front end of the transaction processing 
services at particular nodes. Such firont ends are imple- 
mented" by JAVA viitiial niactiiries,* or by other common 
architectures providing for interconnection of systems 
across a network. Thus, the business interface definition 
provides a technique by which a transaction protocol is 



12 

programmed using the business interface definition docu- 
ment. The program for the protocol of the transaction is 
established by a detailed formal specification of a document 
type. 

An example business interface definition BID based on a 
market participant document which conforms to an XML 
format is provided below. The market participant DTD 
groups business information about market participants, asso- 

10 ciatiog contact and address information with a description of 
services and financial information. Hiis business inforaia- 
tion is composed of names, codes, addresses, a dedicated 
taxonomic mechaiusm for describing business organization, 
and a pointer to terms of business. In addition, the services 

15 identified by the market particq)ant DTD will specify the 
input and output documents which that participant is 
expected respond to and produce. Thus, documents which 
define schema usinjg an exemplary comiiion busliiess 
guage for a market participant DTD, a service DTD, and a 

20 d*ansaction document DTD ^ecified in XML with explana- 
tory comments follow: 



Maricet Participant Sample 

<!C)OCnrPE SCHEMA SYSTEM "bidi.dtd''> 
<SCHEMA> 

<H1 >Market Partic^ant Sample BID^H1> 
<META 

WHO.OWNS»"Vco Systems" WHO.COPYRIOirr-«Vco Systems" 

WHEN COPYRIGHr--1998" DESCRIPTION»"Sample BUT 

WHCCREAIED--*" WHEN.GREATED--*'* 
WHAHVERSION-— ' WHO.MODIFIED-— " 

WHEN.MODIFIEID=— " WHEN.EFFECnVE^"*" 
WHEN.EXFIRES-**" WHO-EFFECnVE-"*" 
WHOJBXPIRES-»"*"> 
<^META> 
<PROL0G> 

<XMLDECL SIANDALONE--no'*></XMLDECL> 
<DOCryPE NAME-"markeLparticq3anf> 
<SYSrrBM>mar]qpart.dtd-c;/SYSTEM>'^/DOCTYPE> 
</FROLOG> 

<DrD NAME»'*iiiaTl£part.dtd"> 

<H2>Markct P^rticq»nt^^/H2> 

<H3>Markct PiarticqMnt<;/H3> 

<ELEMENTrYPE NAM&>''maiketparticipant"> 

<EXPLAIN>4aTrLE>A Market Paiticipaiit</rm£> 

<SYNOPSIS>A business or pcisoa and its seivice interfaces. </SYNOPSIS> 

<P>A mailcet participant is a document defmition that is created to describe a business and at least 

one person with an email address and it presents a set of pointers to service interfaces located on 

the network. In this exan^Ie the pointers have been resolved and the complete BID is presented 

hcrc.</P>/EXPLAIN> 

<MODEL><CHOICE> 

<£LEM£NT NAME-'l3usiness*'>VELEMENlV 
<ELEMENT NAME-'*person'«></EtEMENr> 
</CHOICE></MODEL></ELEMENTTYPE> 
<H3>Party Prototypc</H3> 
<PROTOTYPE NAMB--party"> 

<EXPLAIN><TTrLE>The Party PrGtotype</nTLE></EXPLAIN> 
<MODEI><SEQUENCE> 

<ELEMENT NAME-"party.namc'XXX:URS="+"x/ELEMENT> 

<ELEMENT NAME--addrefis.8et"></ELEMENT> 

</SEQUENCE></MODEL> 

</PRarOTYPE> 

<cH3>Party Typcs</H3> 

<ELEMENTTYPE NAMEa-busincss'V 

<EXPLAIN>^ITrLE>A Business</nTLE> 

<SYNOPSIS>A business (party) with a business number attribute.</SYNOPSIS> 
<P>This element inherits the content model of the party prototype and adds a Imsiness number 
attribute, which serves as a key for dat^rase lookup. The business numlier may be used as a cross- 
reference to^m customer id, credit limits contacts lists, etc<(^></EXPLAIN> 
<EXTENDS HREF«"party'*> 

<ArTDEF KAM£-«nH]siness.numbef^></REQi;iRED><;/REQUtRED>^AnDBF> 
<:/EXrENI>S> 
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</ELEMENTTYPE> 
<II3>Peison Name^II3> 
<ELEMENTrYPE NAME--peraoD"> 
<EXPLAIN><^nTLE>A Pcrcoii<mTLE>/EXPLAIN> 
<EXTENDS HREF--party"> 

<AnDEP NAME-"SSN**><IMPUED>-^MFUED>^AnT>EF> 

</EXTENDS> 

</ELEMErmTfPE> 

<H3>Party Naine^<^> 

<ELEMENTrYPE NAME="party.namc"> 

<EXPLAIN><^nTLE>A Party's Name</nTLE> 

«SYNOPSI5>A paity's name in b string of cliancter.<^SYNOPSIS><^EXPLAIN> 

<MODELxSTRINO><;/SrrRINO><;/MODEL> 

</ELEMENTrYPE> 

<H3>Addres8 S€t</H3> 

<ELEMENTrYPE KAME-"adxircss.sct'*> 

<MODELxSEQUENCE> 

<ELEMENT NAME-"addnsss.physical">^/ELEMENT> 
<ELEMENT NAME-"telcphonc''OCCURS-—''><;/EtEMENTV ' ^ " 
<ELEMENr NAME--fia'XXrURS---><;/ELEMEr^ 
<ELEMENT NAME-"einail'XXXURS-*'**'>s/ELEMENr> 
<ELEMENT NAME--mtcnict'XXXXmS--*">*^LEMENr> 
</SEQUENCE></MODEL> 
<;/ELEME^aTYPE> 
<H3>PliysLcal Address<^/H3> 
<ELEMENTTY?E NAME=''addrcss.physical**> 
<EXPLAIN>-^nTLE>Physical Address .^/TrrLE> 

<SYNOPSIS>The stieet address, dty, state, and zip code.<ySYNOPSIS>^^EXPLAIN> 

<MO0EIx5EQUENCE> 

<ELEMENT NAME-'streee'x/ELEMENIV 

<ELEMENT NAME--city"></ELEMENT> 

<ELEMENT NAME--state"></ELEMENT> 

<ELEMENT NAME--postcodc"OCX:URS--?-></ELEMENT> 

<ELEMENT NAME-"country">VELEMENr» 

</SEQUENCE></MODEL> 

<yELEMENTTYPE> 

<H3>Street<yH3> 

<ELEMENTrYPE NAME-"strcct"> 

<EXPLAIN>^nTLE>Street Address </TITLE> 

<SYNOPSIS>Strect or postal address. VSYNOPS[S><;/EXPLAIN> 

<MODEL>^Sl^(h'<JSnaSO></MODEL> 

</ELEMENTrYPE> 

<H3>City</H3> 

^LEMENTTYPE NAME="city"> 
<EXPIAIN>^nTLE>City Name or Code</TrrLE> 

<P>'Tlie dty name or code is a string that ccmtains su£Scient information to ident^ a city within a 

designated state.<^> 

</EXPLAIN> 

<MODELxSTRINCj>.;/STRING><</MODEL> 

^LEMENTTYPE> 

<K3>State^> 

<ELEMENTryPE NAME--8tate''> 

<EXPLAIN>^riTLE>State, Province or Prefecture Name or GodeVTrnJE> 

<P>The state name or code contains oifSdent information to identfy a state within a designated 

country.<;/Px/EXFL/UN> 

<MODEL>^OTlING DArAITPE-"C(XJNmY.US^UBENTrry">.^/SITUNG>^0^ 

</ELEMENTrYPE> 

<fl3>Fostal Code<JB3> 

kELEMENTTYPE NAME-"po5toode"> 

<EXPLAIN>"<nTLE>Postal Code</TTrLE> 

<P>A postal code is an alphanumeric code, designated by an Expropriate postal authority, that is 

used to identfy a location or region within the jurisdiction of that postal authority. Postal authorities 

indnde designated national postal authorities. </P></EXPLAIN> 

<MODELxSTRING DArArYP&--stxingr><^STRINGx^ODEL> 

-^LEMENTrYPE> 

<H3>Country<c/H3> 

<ELEMENTrYPE NAME=-conntry"> 

<EXPLAIN><^nTLE>Coantry Code</ITrLE> 

<P>A country code is a two-letter code, designated by ISO, that is used to uniquely identfy a 
country. </P >/EXP IJVIN> 

<MODEL>^.STRING DArAryPE-"country*'>-^/SrrRING>'^ODEL> 
<7ELEMENTrYPE> 
<H3>Netwoik Addzesses<yH3> 
kELEMENTTYPE NAMEp.-telcphone"> 
<EXPLAIN><nrrrLE>Tclcphonc Numb6r<TrrLE> 

<P>A telephone number is a string of alphammierics and punctuation that uniquely identifies a 
telephone service terminal, includii^ extension munbeL<P>-</EXPLAIN> 
<MODELxSrRING><;/SrrRING></MODEL> 
</ELEMENTrYFE> 
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<H3>Fax</H3> 

<ELEMENrrYPE NAME--fex'*> 
<EXPLAIN>-^nTLE>Fn Number VnTLE> 

<P>A fax Dumbcf is a string of alphanomerics and punctuatioa that uniquely identifies a &x service 

terminal. </P> 

.^/EXPLAIN> 

<MODELxSlR[N0><;/STR[NO>^OD£L> 

</ELEMENTTYPE> 

<H3>EniaU</H3> 

<ELEMENTrYPE NAME="cmail"> 
<EXPLAIN><frmj£> Email Addrcss</nTLE> 

<P>An email address is a datatype-coostrained string that uniquely identifies a mailbox on a 
scrvcr.</P></EXPLAIN> 

<MODELxSrrRING DArAryPB-**cnwir><^SrrRING></MODEL> 
</ELEMENTrYPE> 
<H3>Intcnict Address ^/H3> 
<EUEMENTTYPE NAME-"mtcmcr> 
<EXPLAIN>.dTrLE>Intemct Addrefi8</nTLE> 

<P>An Internet address is a datatype-con8traitt6d''stni^{ that uhiqdely identifies a resource on the 

Internet by means of a URL</P></EXPLAIN> 

<MODEL5««OTUNG DArArYPE*'^irl**>-</STRING>^ODEL> 

</ELEMENTTYPE> 

<JUrD> 

</SCHEMA> 

Service Dcacription Sample 

<!DOCrYPE scheoui SYSTEM "bidLdtd'V 
<SCHEMA> 

<Hl>Seivice Description Sample BII></H1> 
<META 

WHO.OWNS-"\feo Systems'* WHO.COPYRIGHT-«Vco Systems'* 

WHEN.OOPYRIGHT=-1998r DESCRIPnON=*'Sample BUT 

WHCCREATED-— ' WHEN.CREATED-— ' 

WHAT.VERSION--*" WHO.MODIFIED-"*" 
WHEN.MODIFIEI>--" WHEN.EFFECnVE-— " 

WHEN.EXPIRES--"" WHO.EFFECnVE="*" 
WHO.EXPIRES-"*"> 
</META> 
<PROLOG> 

<XMLDECL STANDALONE--no''>VXMLDECL> 
<DOCTYPE NAME-«5ervice"> 
<SYSrEM>service.dtd</SYSrEM><TOCrYPE> 
<PROLOG> 

<DTD NAME»'service^**> 

<H2>Services</H2> 

<H3>IacIude»^/H3> 

<!- INClXJDE><SYSrEM>comment&bim<^SYSIieM><<;/INCLUD£~> 
<H3>S«vice Set</H3> 
<ELEMENTrYPE NAME-"scrvicc^r> 
<EXPLAIN>*aTrLE>Scrvicc Sct</TrrLE> 
<SYNC^SE5>A set of sendees. <;/SYNOPSISx/EXPLAIN> 
<MODEL> 

<EUEMENT NAME-"sctvicc''OCXnJRS--+-><yELEMENT> 

</MODEL><yELEMENTrYPE> 

<H3>Services Prototype </H3> 

<PROrDTYPE NAME>-**piototype^rvioe'*> 

<EXPLAIN><Trri£>Scrvice<mTlJE></EXPLAIN> 

<MODEL>^EQUENCE> 

<ELEMENT NAME-"servicc.iiame">VELEMENT> 
<ELEMENT NAME»'*servicc,tcrms*XXXURSa*'+'*><;/ELEMENT> 
<ELEMENT NAME»"servicc.location''OCCLRS="+"></ELEMENT> 
<EIJEMENT NAME-"8ervicc.opcration"OCCLRS-*'+"><;/ELEMEhlT> 
<SEQUENCEx/MODEL> 

<!- ATTCROUPxIMPlJEMENTS HREFo-cx>mmoajitrrib'*><;mFLEMEmS><^ArrGROUP 
— > 

</PRaroTYPE> 

<H3>ServLce</H3> 

<INTRO><P>A servke is an addiessable netwodc resource that provides interfaces to specific 
operations by way of input and output documents. </P></INTRO> 
<ELEMENTrYPE NAME--*seivice''> 
<EXPLAIN>^aTrLE>SeiviccVITrLE> 

<P>A service is defined in terms of its name, the Iocatiott(s) at which the service is available, and 

the opeiation(B) that the service perfi>rmfi.</P></EXPLAlN> 

<MODEL9M<SEQUENCE> 

cELEMENT NAME='*5ervice.namc">^/ELEMEhrr> 

<ELEMENT NAME="scrvicc.location''></ELEMENT> 

<ELEMENT NAME-''8ervicc.operation''OCCURS-"+"><;/ELEMENT> 

<ELEMENT NAME="servicc^nns"><ELEMENT^ 

</SEQUENCE></MODEL> 
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</ELEME^^^rYPE> 

<H3>Seivioe Naine</H3> 
<ELEMBNTTYPE NAME-'*scfvice.iiame"> 

<EXPLAIN><aTrLE>Seivicc Name</TrrLE> 

<P>The service name is a human-readable string tliat ascribes a moniker for a service. It may be 

employed is user interfaces and documentation, or for other purposes. </P>5/EXPLAIN> 

<MODEL><STRINO>^/STRIN€}></MODEL> 

</ELEMENTrYPE> 

<H3>Service Ijocation-</H3> 

<ELEMENTTYPE NAME»"servicc.location''> 

<EXPLAIN>^nTLE>Scrvicc Location</rnUE> 

<SYNOPSIS>A LRI of a 8ervioe.^YNOPSlS> 

<P>A service location is a data^pe-constrained string that locates a service oo the [ntemet by 
means of a URI.</P><;/EXPLAIN> 

<MODEL>^.STRING DArAryPB-**uri*'>-«;/STIUNG>^^/MODEL> 

<^LEMENTTYPE> 

<H3>Scrvicc Opc rations </H3> 

<INTRO><P^A service operation consists of a name, location and its interface, as identified by the 
type of inpiiX doaunent ibat the itervidc' operation accepts and by the type of document that it will 
return as a rcsulL<;/P></INTRO> 
<ELEMENTTYPE NAME-**service.operation"> 
<EXPLAIN>-«fnTLE>Scrvicc Opciations</nTLE> 

<P>A seivice operation must have a name, a locaticm, and at least one document type as an input, 
with one or more possible document types returned as a result of the operation.<^> 
<yEXPLAIN> 
<MODELxSEQUENCE> 

<ELEMENT NAME=**servicc.operationjiame''><;/ELEMENT> 

<ELEMENT NAME-"8crvicc.opcrationJocation''><;^LEMENT> 

<ELEMENT NAME-''8ervice.operationiiiput'*>-</ELEMEKr> 

<ELEMENT NAMEa**service.operationjou^t"><^LEMENT^ 

'«;/SEQUENCE></MODEl> 

</ELEMENTTYPE> 

<H3>Senace Operation Name</H3> 

<ELEMENTTYPE NAME-"8ervicc.opeiation.namc'*> 

<EXPLAIN><aTnJE>Service Operation Namc</TrrLE> 

<P>The service operation name is a hunuin readable string that ascribes a moniker to a service 

operation. It may be employed in user interfaces and documentation, or for other 

puiposcs.</Px;/EXPLAIN> 

<MODEI.><SnUNG></SrrRING></MODEL> 

^LEMENTryPE> 

<H3>Service Opeiatiaa Locatba<^H3> 

<INTRO>^ST1ie service location is a network resource. That is to say, a URL^></INIKO> 
<ELEMENTTYPE NAME-'*service.opcration-location'*> 
<EXPLAIN><fnTLE>Scrvicc Operation LocatiDn"</ITrLE> 
<SYNOPSIS>A URI of a service operation.</SYNOPSIS> 

<P>A service operation location is a datatype-constrained string that locates a service operation on 
the Internet by means of a URL.<;/P><;/EXPLAIN> 
<MODEL><SrrRING DArArYPE="urI"><;/STRING></MODEL> 
<;/ELEMENTryPE> 

<H3>Service Operation Input Document^H3> 

<INTROxP>The input to a seivice operatioa is defined by its input document type. That is, the 
service operation is invoked when the service operation location receives an iiqput document whose 
type corresponds to the document type specified by this element <«;/P> 
<P>Rather than define the expected ii^ut and output document types in the market participant 
document, this example provides pointers to extemally-delined BlDs This allows reuse of the same 
BID as the input and/or ou^t document type for mult^Ie operations. In addition, it encourages 
parallel design and implemeQtation.</Px/D'nTlO> 
<ELEMENl i'YPE NAME»'*service.operation.input"> 
<EXPLAIN>'^nTLE>Service Operation Input<</TrrLE> 

<SYNOPSIS>Identifie5 the type of the seivice operation input docunienL</SYNOPSIS> 
<P>Service loo^on input is a datatype^nstnined string that identifies a BID on the Internet by 
means of a URI.<^/P> 
</EXPLAIN> 

<MODELx£rrRING DArArYPE-"Urr></STRING></MODEL> 
^LEMENTTyPE> 

<H3>Scrvicc Opendon Output Document 'IVpc</H3> 

<INTRO><P>The output of a service operation is defined by its output document type(s). That is, 
the service operation is expected to eodt a document whose type oorrei^nds to the document type 
specified by this elemenL<^></INTRO> 
<ELEMENTTYPE NAMEa''service.opeiation-Ouq)Ut"> 
<EXPLAIN><^nTLE>Servicc Operation Output</nTLE> 

<SYNOPSIS>Idcatifics the type of the service operation output document </SYNOPSIS> 
<P>Servioe location output is a datatype-constrained string that irtrntifiM a BID on the Internet by 
means of a URI.VP> 
</EXPLAIN> 

<MODELxSTR!NG DArArYPE--uri"></SrRING></MODEL> 

-^/ELEMENTryPE> 

<H3>Scrvicc Tcnn5<;/H3> 

<INTRO><P>This is a simple collection of string elements, describing the terms of an 
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agiccmcnL ^></Umo> 
<ELEMENTTYPE NAME-**seivice. tenns" > 
<EXPLAIN>VrrrLE>Sexvice lbnnsVITrLE> 
<SYNOPSIS>Dcscribcs the lenns of a given agiecmeiit</SYNOPSIS> 
</EXPLAIN> 

<MODEL>"«STRING DArArYPE-"6trin^'><;/SrRINGx/MODEL> 

smLEMENTrYPE> 

</DTD> 

</SCHEMA> 



The service DTD schema may be extended with a service 
type element in a common business language repository as 
follows: 



<I ELEMENT servicc.type EMFrY> 
<!ArTUSr 8crvicc.typc 

service.type.oame ( 

catalogjopentor 

|oominercial.dLrectory.operator 

eft scrviccs-providcr 

escrower 

fulfUImentservioB 

insurer 

manofacturer 

market.operator 

order.originator 

ordering.8ervice 

persoiiALservices.provider 

retailer 

retaD.aggreg9tor 

schema.resoltttion^rvioB 

shipmcoLacoeptor 

shipper 

van 



The service type element above illustrates iDteipretatioo 
information carried by a business interface definition, in this 
example a content form allowing identification of any one of 
a list of valid service types. Other interpretation information 
includes data typioje, such as for example the element <H3> 
Internet Address </h3> including the content form '^irl" and 
expressed in the data type ''string/' Yet other interpretation 
information includes mapping of codes to elements of a list, 
such as for example the element <H3> State </H3> includ- 
ing the code mapping for states in the file ''COUNTRY.US- 
.SUBENTITY" 

The service description referred to by the market partici- 
pant DTD defines the documents that the service accepts and 
generates upon competition of the service. A basic service 
description is specified below as a XML document trans- 
actxltd. 



Transact.dtd models a transaction description, such as an 
invoice, or a description of an exchange of value. This 
document type supports many uses, so the transaction 
description element has an attribute that allows user to 
distinguish . among invoices, performance, offers..tp_sell, 
requests for quotes and so on. The exchange may occur 
among more than two parties, but only two are called out, 
the offeror and the counter party, each of whom is repre- 
sented by a pointer to a document conforming to the market 
participant DTD outlined above. The counter party pointer is 
optional, to accommodate offers to sell. The exchange 

25 description is described in the module tranprim.mod listed 
below, and includes pricing and subtotals. Following the 
exchange description, charges applying to the transaction as 
a whole may be provided, and a total charge must be 
suppHed. Thus, the transaction description schema docu- 

30 ment transact.dtd for this example is set forth below: 



Representative market participant, and service DTDs, 
created according to the definitions above, are as follows: 



<!- tnmsactdtd Vemion: 1.0 ~> 
<t- Oopyiight 1998 Vbo Systems, Inc. -> 
35 . . . 

<!ELEMENT transactioadestn^tion (meta?, issuer.pointer, 

counterpaity.pointer?, cj^iangc-descrptioQ-t-, ^ncralchaigcs?, 
ncLlolal?)> 
<iAITLIST tiaosactioiLdescrqition 

transactio&.type (invoice ) pro. forma | oSeLto.sell | order 
40 |reqaesLfor.quote | rcquestfoLbid 

IreqaesLfDr^roposal | response.tarequest.for.quote 
jreqionsctarequestfcrbid 
|re8poiise.tarequestfor.proposal) 'invoice** 
%oominon.attrib; 
%altrep.attrLb; 
%tU.attrib; 

45 



Market Paiticqant DTP 

<>ELEMENT business ^rty.naine+, ftddress.set)> 

<! ATTUST business busines8.oumber CD^A #REQU(RED 

> 

<!ELEMENT party.name (#PCDArA)> 
<!EUEMENT city (#PCDArA)> 
<! ELEMENT interact (#PCDArA)> 
<! ELEMENT country (#PCX>ArA)> 
<IELEMEKr state (#PCDArA> 
<!ELEMENT email («»CDArA> 

<I ELEMENT addiess.physical (street, dty, state posteode?, ccKuitry)> 

<IELEMEI^ telephone (HPCDArAy> 

<! ELEMENT person (paity.name-t-, address.set)> 

<! AETUST person SSN CDATA MMPUED 



11/19/2003, EAST Version: 1.4.1 



6,125,391 



21 



-continued 



<!ELEMENT fax (#PCDArA> 
<IELEMENT street (#FCDArA)> 

<!ELEMENT eddress^t (addie88.phy8tcal, telephone*, &x*, email*, mtemet*)> 

<!ELEMENT postcode («<:DAIA)> 

<I ELEMENT inarket.paitk^»uit (business | peTson)> 

Seivioe DTD 

<! ELEMENT servicdocation (#PCDArA)> 
<! ELEMENT serwicctenns (#PCDArA)> 
-clELEMENTscrviccopcration-namc (#PCDArA)> 

<! ELEMENT service.opeiation (service.operatlon.iiaine^ serviccoperadoiiJocalion, 
service.operatioQ. input, serviccopeiBtioo. output)> 

<! ELEMENT service (scrvicc.namc, service-locatioa, service.opcration-t-, scivice.tenns) > 

<! ELEMENT serviccopcralion. input {4fBCDAIA)> 

<!ELEMENT service-opcration. location («»CDArA)> 

<!ELEMENT scrviccnamc (#PCDArA)> 

<! ELEMENT service.set (scrvic»+)> 

<l ELEMENT service.operation-ou^ut (#PCDArA)> 



One instance of a document produced according to the 
transact.dtd follows: 



<?xml version-"! .0"?> 
<!-ronierjiml Version: 1.0 — > 
<ICopyngbt 1998 Vco Systems, Inc. ~> 

<IDOCryPE tnnsactioadescription SYSTEM *^iin3i-veo8y8tems:dtdxbl:tnsaact: 1.0:> 



<meta> 

•cum ?um3-voosyB terns :docK)0023 
<Aini> 

•dhreadid party assignfti by°"ieqoig">t*Rni76 
<^t]iread.Ld> 

</meta> 

^sstier.poLnter> 



<zU.Iocator urllinkB**cQmpnjEml">CataI(^ entry owner 
pointer 
<;MlJocator> 
</counterpaity.pouitez> 
<exchacge.descTiption> 
<luieatcm> 

<pioduct instanco 
<productdescrq>ti0n4>ointer> 

<dl.Iocator urll^i]^**cthittk.xml''>CBtalogue Eotry Pointer 
<xU.Iocator> 
^rod uct .description.pointer> 
<|>roducLspedfics> 
^jifo.descriptionjset> 
<info.description> 
<iEml.descrq>tor> 

<doctype> 

<dtd 8ystemid**um3C*veosystems:dtd:d>l:gprod:l.(r/> 
<doctype> 

^ml.dcscriptor.detaiLs> 

<zUjq)trirag>DESCENDANTXALL, os)STR[NGC^indows 
^Lxpt].(iBg> 

<;Wl.xptr.frag5^DECENDANT(ALL,p.specd)STRING("200'^ 
<;Wl.xptLfrBg> 

</xll.xptLfrag>DESCENDANT(ALL,haid.disk.capacity) 

SnUNGCA'O 

<;^l.xpti.frBg> 

<(xUjqiti.fr9g>DESCENDANIXALL,Asize)SnUNG(-14.^ 

^xll.xpti.£rag> 

<;/xml.descrq)toLdetails> 
</xnil.dcscriptor> 
<Anfo.descriptioa> 

<^info.description.set> 

</product.$peGific5> 




<xll. locator urllink-''reqorgjEmr'>CU8tomer 
Pointer 
<MUocator> 



^is8uer.pototei> 



<connteipaity.pointei> 
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</q[uantity>l 
^qiiaiitity> 

-^roductinstanoo 
<shipmenLcoordmates.set> 
<shipinenLcoordinates> 
<slupittentdestination> 

<addiess.set> 
<address.nained>SW-l 
«iiddress.nanied> 
<addrcss.physical> 

<builduig^biocatioii>208C^mldiEg.subloc8tion> 

<locatioiL in. Btreel>123 

</IocatioQ.in. stioet> 

<street>FiontagB Rd. 

</street> 

<city>Bellway 

<fchy> 

<cottatiy.subeiUity.us 

ooaiitiyjsubeiiUty.ua.iiame>»'*MI>^/> ' 

<postcode>20000 

<postoode> 
<;^addics$.phy8ical> 
<ielephoiie> 

<telephonejiiimber>617-666-2000 

<^Iqihone.aumbei> 

<telephoae.exteiisioii>12Ql 

</teIephone.extenstoit> 
<^telephone> 

'</shipinent,dastination> 

</shipineiitspecifil>No deliveries after 4 PM'^hq}inent8pectal> 

<^h^>inenLcoordiiiatc$> 
<;/shq>ineiiLcoordiQates.set> 

<paymentset> 

<ciedit.card 

issuer.naine»**VISA" 

instnimeiiLaumbcr-"3787-n812345-<7893" 

eaqjiry-datc-** 12/97** 

airrcncy.oodc='*USD^> 

-canioiuitgiDup> 

oinouiiLinoiietary ciirrencyxodD«''USiy*>3975 
^amoi]nLmoiietary> 

</ainouatgn>iqp> 

<ypayinentset> 
</lme.item> 
^e)d)angp.descrqAioii> 
^tansaclioiLdescrtpt£on> 



Accordingly, the present invention provides a technique 
by which a maiickct participant is able to identify itself, and 
identify the types of input documents and the types of output 
documents with which it is willing to transact business. The 
particular manner in which the content carried in such 
documents is processed by the other parties to the 
transaction, or by the local party, is not involved in estab- 
lishing a business relationship nor carrying out transactions. 

FIG. 3 provides a simplified view of a participant node in 
the network according to the present invention. The node 
illustrated in FIG. 3 includes a network interface 300 which 
is coupled to a communication network oo port 301. The 
network interface is coupled to a document parser 301. The 
parser 301 supplies the logical structures firom an incoming 
document to a translator module 302, which provides for 
translating the incoming document into a form usable by the 
host transaction system, and vice versa translating the output 
of host processes into the format of a document which 
matches the output document form in the business interface 
definition for transmission to a destination. The parser 301 
and translator 302 are responsive to the business interface 
definition stored in the participant module 303. 

The output data structures from the translator 302 are 
supplied to a transaction process front end 304 along with 
events signaled by the parser 301. The front end 304 in one 
cmtxxlimcnt consists of a JAVA virtual machine or other 



similar interface adapted for communication amongst 
diverse nodes in a network. The transaction processing front 
end 304 responds to the events indicated by the parser 301 
and the trat^ator 302 to route the incoming data to appro- 
priate functions in the enterprise systems and networls to 
which the participant is coupled. Thus, the transaction 
process front end 304 in the example of FIG. 3 is coupled to 

50 commercial functions 305, database functions 306, other 
enterprise functions such as accounting and billing 307, and 
to the specific event listeners and processors 308 which are 
designed to respond to the events indicated by the parser. 
The parser 301 takes a purchase order like that in the 

^5 example above, or other document, specified according to 
the business interface definition and creates a set of events 
that are recognized by the local transaction processing 
architecture, such as a set of JAVA events for a JAVA virtual 
machine. 

The parser of the present invention is uncoupled from the 
programs that listen for events based on the received docu- 
ments. Various pieces of mark-up in a received document or 
a complete document meeting certain specifications serve as 
instructions for listening functions to start processing. Thus 
listening programs carry out the business logic associated 
65 with the document inforaaation. For example, a program 
associated with an address element may be code that vali- 
dates the postal code by checking the database. These 
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listeners subscribe to events by registering with a document 
router, which directs the relevant events to all subscribers 
who arc interested in them. 

For example, the purchase order specified above may be 
monitored by programs listening for events generated by the 5 
parser, which would connect the document or its contents to 
an order entry program. Receipt of product descriptions 
within the purchase order, might invoke a program to check 
inventory. Receipt of address information within the pur- 
chase Older, would then invoke a program to check avail- 
ability of services for delivery. Buyer information fields in 
the document, could invoke processes to check order history 
for credit worthiness or to offer a promotion or similar 
processing based on knowing the identity of the consumer. 

Gomplex listeners can be created as configurations of 
primitive ones. For example, a purchase order listener may 
contain and invoke the list listeners set out in the previous 
paragraph, or the list members may be invoked. on their own. 
Note that the applications that the listeners run are unlikely 
to be native y^AL processes or native JAVA processes. In 
these cases, the objects would be transformed into the format 
required by the receiving trans application. When the appli- 
cation finishes processing, its output is then transformed 
back to the XML format for communication to other nodes 
in the network. 

It can be seen that the market participant document type 
description, and the transaction document type description 
outlined above include a schematic mapping for logic ele- 
ments in the documents, and include mark-up language 
based on natural language. The natural language mark-up, 
and other natural language attributes of XML facilitate the 
use of XML type mark-up languages for the specification of 
business interface definitions, service descriptions, and the 
descriptions of input and output documents. 

The participant module 303 in addition to storing the 
business interface definition includes a compiler whidi is 
used to compile objects or other data struaures to be used by 
the transaction process front end 304 which corresponds to 
the logical structures in the incoming documents, and to 
compile the translator 302. Thus, as the business interface 
definition is modified or updated by the participant as the 
transactions with which the participant is involved change, 
the translator 302 and parser 301 are automatically kept up 
to date. 

In a preferred system, the set of JAVA events is created by 
a compiler which corresponds to the grove model of SGML, 
mainly the standard Element Structure Information Set 
augmented by the "property set" for each element. Interna- 
tional Standard ISOIIEC 10179:1996 (£), Information 
Technology-Processing Languages^)ocument Style 
Semantics and Specification Language (DSSSL). 1\iming the 
XML document into a set of events for the worid to process 
contrasts with the normal model of parsing in which the 
parser output is maintained as an internal data structure. By 
translating the elements of the XML document into JAVA 
events or other programming structures that are suitable for 
use by the transaction processing front end of the respective 
nodes enables rich functionality at nodes utilizing the docu- 
ments being traded. 

Thus, the transaction process front end 304 is able to 
operate in a publish and subscribe architecUire that enables 
the addition of new listener programs without the knowledge 
of or impact on other listening programs in the system. Each 
listener, 306, 306, 307, 308 in FIG. 3, maintains a queue in 
which the front end 304 directs events. This enables multiple 
Usteneis to handle events in parallel at their own pace. 

Furthermore, according to the present invention the appU- 
cations that the listeners run need not be native XML 
functions, or native functions which match the format of the 



incoming document. Rather, these listeners may be JAVA 
fiinctions, if the transaction process front end 304 is a JAVA 
interface, or may be functions whidi mn according to a 
unique transaction processing architecture. In these cases, 
the objects would be transformed into the format required by 
the receiving application. When the application of the lis- 
tener finishes, its output is then transformed back into the 
format of a document as specified by the business interface 
definition in the module 303. Thus, the translator 302 is 
coupled to the network interface 300 directly for supplying 
the composed documents as outputs. 

The listeners coupled to the transaction processing front 
end may include listeners for input documents, listeners for 
specific elements of the input documents, and listeners for 
attributes stored in particular elements of the input docu- 
ment. This enables diverse and flexible implementations of 
transaction processes at the participant nodes for filtering 
and responding to incoming documents. 

FIG. 4 illustrates a process of receiving and processing an 
incoming document for the system of FIG. 3. Thus, the 
process begins by receiving a document at the network 
interface (step 400). The parser identifies the document type 
(401) in response to the business interface definition. Using 
the business interface definition, which stores a DTD for the 
document in the XML format, the document is parsed (step 
402). Next, the elements and attributes of the document are 
translated into the format of the host (step 403). In this 
example, the XML logic stmctures are translated into JAVf\ 
objects which carry the data of the XML element as well as 
methods associated with the data such as get and set func- 
tions. Next, the host objects are transferred to the host 
transaction processing front end (step 404). These objects 
are routed to processes in response to the events indicated by 
the parser and the translator. The processes \^ch receive 
the elements of the document are executed and produce an 
output (step 405). The output is translated to the format of 
an output document as defined by the business interface 
definition (step 406). In this example, the translation pro- 
ceeds from the form of a JAVA ol^ect to that of an XML 
document. Finally, the output document is transmitted to its 
destination throug^b the network interface (step 407). 

FIG. 5 is a more detailed diagram of the event generator/ 
event listener mechanism for the system of FIG. 3. In 
general the approach illustrated in FIG. 5 is a refinement of 
the JAVA JDK 1.1 event model. In this model, three kinds of 
objects are considered. A first kind of object is an event 
object which contains information about the occurrence of 
an event. There may be any number of kinds of event 
objects, corresponding to all the different kinds of events 
which can occur. A second kind of object is an Event 
generator, which monitors activity and generates event 
objects when something happens. Third, event listeners, 
listen for event objects generated by event generators. Event 
listeners generally listen to specific event generators, sudi as 
for mouse clicks on a particular window. Event listeners call 
an "ADD event listener" method on the event ^nerator. 
This model can be adapted to the environment of FIG. 3 in 
which the objects are generated in response to parsing and 
walking a graph of objects, such as represented by an XML 
document. 

The system illustrated in FIG. 5 includes a generic XML 
parser 500. Such parser can be implemented using a standard 
call back model. When a parsing event occurs, the parser 
calls a particular method in an application object, passing in 
the appropriate information in the parameters. Thus a single 
application 501 resides with the parser. The application 
packages the information provided by the parser in an XML 
event object and sends it to as many event listeners as have 
identified themselves, as indicated by the block 502. The set 
of events 502 is completely parser independent. The events 
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502 can be supplied to any number of listeners and any <PURCHASES HTML-"OL"><ITEM HTML= 

number of threads on any number of machines. The events "LKxNAME HTML = "B">STUFF</ 

are based on the element structure information set ESIS in NAMExPRICE HTML="B">123</PRICE></ 

one alternative. Thus, they consist of a list of the important IT£M></PURCHASES> 
aspects of a document structure, such as the starts and ends s translates into: 

of elements, or of the recognition of an attribute. XML (and <OL><L]>.<B>STUFF'</B><B>123</B></LI></OL> 

SGML) parsers generally use the ESIS structure as a default which is correct HTML. 

set of information for a parser to return to its application. The next module which is coupled to the set of events 502 

A specialized ESIS listener 503 is coupled to the set of ^^"^ "^f buUder takes astream of XML 
JZm TL.' I- * CM' 1 * *t. ccic 1- * 10 events and generates a tree representation of the underlying 

events 502 This l^tener 503 implement the ESIS listener document. One preferred ve^ion of the tree builder 506 

API, and hstens for all XML events from one or more oe^^tes a document object model DOM object 507, 

generators. An element event generator 504 IS a speciahzed according to the specification of the W3C (See, http:// 

ESIS listener which is also an XML event generator. Its www.w3.org/TR/1998/WD-DOM-19980720/ 

listeners are objects only interested in events for particular introduction.html). However listeners io event streams can 

types of elements. For example in an HTML environment, be used to handle most rcquirenaents, a tree version is useful 

the listener may only be interested in ordered lists, that is for supporting queries around a document, reordering of 

only the part of the document between the <OL> and </0L> nodes, creation of new documents, and supporting a data 

tags. For another example, a listener may listen for "par- structure in memory from which the same event stream can 

ty.name" elements, or for '^servioe.name*' elements accord- be generated multiple times, for example like parsing the 

ing to the common business language, from the example document many times. A specialized builder 508 can be 

documents above, process the events to ensure that the coupled to the tree builder 506 io order to build special 

elements carry data that matches the schematic mapping for subtrees for parts of the document as suits a particular 

the element, and react according to the process needed at the implementation. 

receiving node. addition to responses to incoming documents, other 

25 sources of XML events 502 can be provided. Thus, an event 

This allows the system to have small objects that listen for stream 510 is generated by walking over a tree of DOM 

particular parts of the document, such as one which only objects and regenerating the original event stream created 

adds up prices. Since listeners can both add and remove when the document was being parsed. This allows the 

themselves from a generator, there can be a listener which system to present the appearance that the document is being 
only listens to for example the <HEAD> part of an HTML 30 parsed several times. 

document. Because of this and because of the highly recur- The idea of an object which walks a tree and generates a 

sive nature of XML documents, it is possible to write highly stream of events can be generalize beyond the tree of DOM 

targeted code, and to write concurrent listeners. For objects, to any tree of objects which can be queried. Thus, 

example, an <01> listener can set up an <U> listener a JAVA walker 512 may be an plication which walks a tree 
completely separate from the manner in which the <UL> 35 of JAVA bean components 513. The walker walks over all 

(unordered list) listener sets up its <LI> listener. Ac pubUcly accessible fields and metf^^^^ 

Alternatively, it can create a listener which generates a f ?/ °^J^^^ '^fVJSi!'^ ^.^"^"t^ 

graphicuserintcrfaceand anotherwhichsearchetadatabase *° ^""^ Tk^^' ^^^^"^^""^ U^"" 

■ ^ J * * * J type of events generated by the JAVA walker 512. This 

using the same mput TTttB. the documents treated as a ^ j^'^ information one can 

program executed by Uie hsteners. as opposed to the finished 40 ^^^^ ^ ^ ^hj^ ^ j^^^ equivalent of ESK 

data s ructure which the apphcalion examines one piece at a ^ the same programming approach appUed to XML 

ume. If an application is wnlten this way, it is not necessary ^ be applied to JAVA objects generaUy, although particu- 

to have the entire document in memory to execute an j^^iy (q jy^vA beans. 

appUcation. The JAVA to XML event generator 515 constitutes a JAVA 

The next listener coupled to the set of events 502 is an listener wd a JAmeventgpneraton^^ 

attribute filter 505. The attribute filter 505 like the element *t 512 smd translates selected 

filter 504 is an attribute event generator according to the to present a J/WAol^ect as an XML document. In the 

T-cfo V ♦ ^1 m. f • c « ? one prefeired embodiment, the event generator 515 exploits 

ESIS listener modeL The listener for an attribute filter ta\/a u Anicuu * i i * 

•c .1. n_ . ■ . .J- J . the JAVAbeansAPI. Each object seen becomes an element, 

specifies the attributes it is interested m, and re^^ives events ^j^^^^^ ^^^^ ^^^^ ^ 

for any element havmg that attribute specified. So for ^l^m^nU each embedded method also becomes an 

example, a font manager might receive events only for clement whose content is the value returned by invoking the 

elements havmg a font attribute, such as the <P FONT- method. If it is an object or an array of objects, then these 

"limes Roman" /P>. are walked in turn. 

The element event generator 504 suppUes such element 55 ^ \ % particular application built on the 

objects to specialize the element listeners 504A. ^"^^^""'Kal 5- This application takes m an XML 

document 600 and applies it to a parser/generator 601. ESIS 

The attribute event generator 505 supplies the attribute events 602 are generated and supplied to an attribute gen- 
event objects to attribute listeners 5(^A. Similarly, the erator 603 and tree builder 604. The attribute generator 
attribute objects arc supplied to a "architecture" in the sense corresponds to the generator 505 of FIG. 5. It supplies the 
of an SGML/XML transformation firom one document type events to the "architecture" 505B for translating the XML 
to another using attributes. Thus the architecture of 505B input to an HTML output for example. These events are 
allows a particular attribute with a particular name to be processed in parallel as indicated by block 605 and pro- 
distinguished. Only elements with that attribute defined cessed by listeners. The output of the listeners are supplied 
become part of the output document, and the name of the to a document writer 506 and then translated back to an 
element in the output document is the value of the attribute 65 XML format for output. Thus for example this application 
in the input document For example, if the architecture 505B illustrated in FIG. 6 takes an XML document and outputs an 
is HTML, the string: HTML document containing a form. The form is then sent 
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to a browser, and the result is converted back to XML. For example, an order entry BID 806, an order tracking BID 

this exercise, the architecture concept provides the mapping 807, an order fulfilhnent BID 808, and a catalog service BID 

from XML to HTML. The three architectures included in 809 could be stored. As a new participant in the market 

FIG. 6 include one for providing the structure of the HTML builds a business interface definition, it may select the 
document, such as tables and lists, a second specifying text ^ business interface definitions of sundardized services stored 

to be displayed, such as labels for input fields on the browser t^e repository 

document and the third dcso*^ the input fields them- [□ addition to the party and service BIDs, input and output 

^SiJ'tSe^!?^"!^^^^ rfiTnT^^^^^^ i reix^sjo^^ i^^^^^^ 

fields in the HTML form. TTiis is useful for use in iccon. ^5 ^^^^ ^"fi ^ ^"^^^n '° Twl^ 

structioD of the XML document &om the information the lo ^.T^^I""' "^""T ^l/i? ^^^^ u^^^'^'^l 

cKem wiU put into the HTTP post message that is sent back f^P^^ ^l^' ^° status BID 815 might be stored 

to the server. Each architecture takes the input document and ^ repository. 

transforms it into an architecture based on a subset of The repository, m addition to the busmess mterface defi- 

HTML. Listeners listening for these events, output events nitions which in a preferred system are specified as docu- 

for the HTML document, which then go to a document ^YPe definitions according to XML, stores interpreta- 

writer object The document writer object listens to XML ^on information in the form of semantic maps as indicated 

events and turns them back into an XML document. The ^y the field 816. Thus, semantic maps which are used for 
.. document, writer object is a listener, to all the element .. specifying weights, 817, curr^^^^^^^ 

geoeratois listening to the architectures in this example. identifiers 820, and product features 821 in this example 

The organization of the processing module aiustrated in might be stored in the repository. Further, the interpretation 

FIGS. 5 and 6 is representative of one embodiment of the information provides for typing of data sUructures within the 

parser and transaction process &ont end for the system of logical structures of documents. 

FIG. 3. As can be seen, a very flexible interface is provided lo addition, logical structures used in the composing of 

by which diverse transaction processes can be executed in business interface definitions could be stored in the reposi- 

response to the incoming XML documents, or other struc- tory as indicated by block 822. Thus, forms for providing 
tured document formats. ^5 address information 823, forms for providing pricing infor- 

FIG. 7 illustrates a node similar to that of FIG. 3, except mation 824, and forms for providing terms of contractual 

that it includes a business interface definition builder module relationships could be provided 825. As the network 

700, Thus, the system of FIG. 7 includes a network interface expands, the CBL repository will also expand and standard- 

701, a document parser 702, and a document translator 703. ize tending to make the addition of new participants, and the 
The translator 703 supplies its output to a transaction 30 modification of business interface definitions easier, 
processing front end 704, which in turn is coupled to FIG. 9 illustrates the process of building a business 
listening functions such as commercial functions 705, a interface definition using the system of FIG. 7. The process 
database 706, enterprise functions 707, and other generic begins by di^laying a BID builder graphical interface to the 
listeners and processors 708. As illustrated in FIG. 7, the user (step 900), The system accepts user input identifying a 
business interface definition builder 700 includes a user 33 participant, service and document information generated by 
interface, a common business library CBL repository, a the graphical interface (step 901). 

process for reading complementary business interface Next, any referenced logical stmctures, interpretation 

definitions, and a compiler. The user interface is used to information, document definitions and/or service definitions 

assist an enterprise in the building of a bu^ness interface are retrieved firom the repository in response to user input via 

definition relying on the common business library the graphical user interface (step 902). In the next step, any 

repository, and the ability to read complementary business complementary business interface definitions or components 

interface definitions. Thus, the input document of a comple- of business interface definitions are accessed firom other 

mentary business interface definition can be specified as the participants in the network selected via user input, by 

output docvument of a particular transaction, and the output customized search engines, web browsers or otherwise (step 

document of the complementary business interface defini- 903). A document definition for the participant is created 
tion can be specified as the input to such transaction process. 45 using the information gathered (step 904). The translators 

In a similar maimer a transaction business interface defini- for the document to host and host to document mappers are 

tion can be composed using components selected from the created by the compiler (step 905). Host architecmre data 

CBL repository. The use of the CBL repository encourages structures corresponding to the definition arc created by the 

the use of standardized document formats, such as the compiler (step 906), and the business interface definition 
example schema (bidl) documents above, logical strucmres 50 which has been created is posted on the network, such as by 

and interpretation information in the building of business posting on a website or otherwise, making it accessible to 

interface definitions which can be readily adopted by other other nodes in the network (step 907). 

people in the network. Business interface definitions tell potential trading part- 

The business interface definition builder module 700 also ners the online services the company offers and which 

inchides a compiler which is used for generating the trans- documents to use to invoke those services. Thus, the services 

lator 703, the objects to be produced by the translator are defined in the business interface definition by the docu- 

according to the host transaction processing architecture, menls that they accept and produce. This is illustrated in the 

and lo manage the parsing function 702. following fragment of an XML service definition. 

FIG. 8 is a heuristic diagram showing logical stmcturss 
stored in the repository in the business interface definition 

builder 700. Thus, the repository storage representative ^ — — .^^^^.^^^^^^^^^^^^ 

parly business interface definitions 800, including for <scivice> 

example a consumer BID 801, a catalog house BID 802, a <8crvice.Mme>OrdcrScrvicc-^6emce.namc> 

warehouse BID 803, and an auction house BID 804. Thus, ocna«.lo«Uon>ww.vcosystcm5.can,/onlcr./^ 

<scrviccop> 

a new participant in an onUne market may select as a basic <scrvice.op.naine>Submit OrderW8efvice.op.naine> 

interface description one of the standardized BIDs which <scrvice.op.mputdoc>www.ooiimieroe.net;pa^ 

best matches its business. In addition, the repository will <service.op.outpittdoc> 
store a set of service business interface definitions 805. For 
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year** in Europe vs "month/day/year" in the U.S. are 

-continued encoded in separate CBL modules). 

— The CBL is a language that is used for designing appli- 

www.vcosystcms.coin/invo[cc.d{d^rvicc.op.outpmdoc> cations. It is designed to bridge the gap between the "docu- 

<;^rvioe.op> mcnt world" of XM L and tbe "programming world" of JAVA 

<8eivice.op> ^ ^ ^ . or Other transaction processing architectures. Schema 

^rr^^^^L^Int!!^^^^^ embodies a phUosophy of "programming with documents" 

<seivice.op.mpuUj(>c>www.comineice.iiet . » jtj 

Acau«stiraclLdui<8eivicc.^ ^ ^ich a detailed formal specification of a document type 

<scrvicc.op.outputdoo IS the master source from which a variety of related forms 

wvrw.veosystoms.Goiii/respoiise.tiack.dtd<service.op^^ Can be generated. These forms include XML DTDs for CBL, 

^ivioe.op> 10 JAVA objects, programs for converting XML instances to 

<Jsciykc> and from the corresponding JAVA objects, and supporting 

documentatioiL 

Ti.- vxMT c . J c c . The CBL creates a single soiu-ce from which almost all of 
nus XML fra^ent defin^ a seivioe consistmg of two -^^^ ^ ^ automatically generated by a 
transacdoiK, one for takmg orders and the other for tracking compiler. The CBL works by extending SGMUXML, which 
them. Each definition expresses a contract or promise to is normaUy used to formally define the strucnires of par- 
carry out a service if a valid request is submitted to the ticular document types, to include specification of the 
specified Web address. The Order service here requires an semantics associated with each information element and 
input document that confonns to a standard ''po.dtd" Docu- atuibule. The limited set of (rnostly) character types" in 
mem TVpe Definition located in the repository, which may SGMUXML can be extended to declare any kind of 
be bcal, or stored in an industry wide registry on the 20 datatype. 

network. If a node can fulfill the order, it will return a Here is a fi^agment fix)m the CBL definition for the 

document conforming to a customized "invoice.dtd" whose "datetime** module: 
definition is local. In effect, the company is promising to do 
business with anyone who can submit a Purchase Order that 

conforms to the XML specification it declares. No prior ^5 — — — 

arrangement is necessary. <i~ datettmcmod Wnioa: 1.0 »> 

The DTD is the formal specification or grammar for Copyright 1998 Veo Systems, Inc. -> 

documents of a given type; it describes the elements, their ■ ; ■ /jid-^atan 

attributes, and the order in which they must appear. For ^iSn^V^ 

example, purchase orders typically contain the names and schema CDArA#FiXED*^ai-veoBystems:8ids:iso:860i:3.8" 

addresses of the buyer and seller, a set of product > 

descriptions, and associated terms and conditions such as <!ELEME^r^ month (#PCDArA)> 

price and delivery dates. In Electronic Data Interchange EDI <iArTLiST month 

for example, the X12 850 specification is a commonly used ^ '""^"^ CDATAtFIXED '*urlat.vco3ystcms:std8:iso:8601:3.12" 
model for purchase orders. 

The repository encourages the development of XML 35 

document models firom reusable semantic components that 

are common to many business domains. Such documents 1° fragment, the ELEMENT "year" is defined as 

can be understood from their common message elements, character data, and an associated "schema" attribute, also 

even though they may appear quite different. This is the role character data, defines the schema for "year" to be section 

of the Common Business Library repository. 40 3.8 of the ISO 8601 standard. 

The Common Business Library repository consists of This "datetime** CBL module is in fact defined as an 

information models for generic buaness concepts including: instance of the Schema DTD. First, tbe module name is 

business description primitives like companies, services, '^^^ "datetime" element "YEAR" is bound to 

and products; *^ the semanUcs of ISO 8601: 

business forms like catalogs, purchase orders, and 45 
invoices; 

standard measurements, date and time, location, classifi- <tDOCryFE schema system ''scheina.dtii"> 

cation codes. <SCHEMAxI{l>Date and Time Modiile</H]> 

7^^?T^^^ V,'^^^ extensible. pubKc '.ii^MNrmE NAME.>«-DAI»rYPB.-YEAR-xMODEl> 

set of XML buildmg blocks that companies can customize 50 <STRlNO 

and assemble to develop XML applications quickly. Atomic DAI>a^E-*YEAR*'x/STRING><^ODEL> 

CBL elements implement industry messaging standards and <ArTDEF NAME-tscbcmaasoSfiOl*' DArArYPE-*'CDAlA"> 

conventions such as standard ISO codes for countries, <fked>3.8 

currencies, addresses, and time. Low level CBL semantics ca^cndarVFDCED>^A^roEF></ELEME^mTPE> 
have also come fi-om analysis of proposed metadata frame- 
works for Internet resources, such as Dublin Core. 

The next level of elements use these building blocks to The example market participant and service modules 
implement the basic business forms such as those used in above are also stored in the CBL repository. 
X12 EDI transactions as well as those used in emerging In FIG. 10, an Airbill 1000 is being defined by custom- 
Internet standards such as OTP (Open Trading Protocol) and izing a generic purchase order DTD 1001, adding more 
OBI (Open Buying on the Internet). ^ specific information about shipping weight 1002. The 

CBL's focus is on the functions and information that are generic purchase order 1001 was initially assembled from 

common to all business domains (business description the ground up out of CBL modules for address, date and 

primitives like companies, services, and products; business ' time, currency, and vendor and product description. Using 

forms like catalogs, purchase orders, aixi invoices; standard CBL thus significantly speeds the development and imple- 

measurements, date and time, location, classification codes). 65 mentation of XML commerce applications. More 

CBLbuikls on standards or industry conventions for seman- importantly, CBL makes it easier for commercial applica- 

tics where possible (e^^ the rules that specify "day/month/ tions to be intcrcomiected. 
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Id the CBL, XML is extended with a schema. The 
extensions add strong-typing to XML elements so that 
content can be readily validated. For example, an element 
called <CPU_clock__^eed> can be defined as an integer 
with a set of valid values: {100, 133, 166, 200, 233, 266 
Mhz.}. The schema also adds class-subclass hierarchies, so 
that information can be readily instantiated from class 
definitions. A laptop, for instance, can be described as a 
computer with additional tags for features such as display 
type and battery life. These and other extensions facilitate 
data entry, as well as automated translations between XML 
and traditional Object-Oriented and relational data models. 



Thus the completed BID is run through the compiler 
which produces the DTDs for the actual instance of a 
participant and a service as outlined above, the JAVA beans 
which correspond to the logical structures in the DTD 
5 instances, and transformation code for transforming from 
XML to JAVA and firom JAVA to XML. In alteraaUve 
systems documentation is also generated for display on a 
user interface or for printing by a user to facilitate use of the 
objects. 

For the example market participant and service DTDs set 
forth above, the JAVA beans generated by the compiler are 
set forth (with some redactions for conciseness) as follows: 



import com.vco.vsp.doclct.incta. Document; 
ptiblic class AddiessPhyslcal extends Document { 

public static final Stiing DOC_TYPE « "address-physicar'; 

String mStreetr - • " - " "^ • 

String mCity; 

public final static int AK » 0; 
public final static int AL - 1; 
public final static int AR » 2; 
public final static int AZ - 3; 
public final static int CA - 4; 
public final static int WI » 48; 
public final static int WV = 49; 
public final static int WY - 50; 

int mState; 

String mPostcode; 
public final static int AD - SI; 
public final static int AE ° 52; 
public final static int AF • S3; 
public final static int AG - 54; 
public final static int Al » 55; 
public final static int AM = 56; 

int mCoontry; 
public AddressFhysical( ){ 

5upcr(DOC_TyPE); 
mStieet - new String( ); 
mCity " new String( ); 

this.mState = -1; 
mPostcode - null; 

this.mOountry* -1; 

} 

public AddressPhysical(String docL.type){ 

8upci(doc_typc); 
mStreet » new String( ); 
mCity - new String( ); 

this.mState - -1; 
mPostcode ■> null; 

this.mCountry - -1; 

} 

static public AddressPliysical imtAddressPhysicaI(String iStreet^Stiing iCity,int 
iStBte,String iPo6tcode,int iCountry){ 

AddressPhysical obj = new Addres8Phy8ical( ); 
obj.initiali2eAU(iStreet, iCity, iState, iPostcode, iCbuntiy); 
return obj; 

} 

public void initializ&AU(String iSt»et,String iCity^ iState,Strittg iPostcode^t 
iConntry){ 

mStrcet = iStrcct; 
mCity = iCity; 
mState - iState; 
mPostcode = iPoslcodc; 
mCountry « iCountry; 

public String getStreet( ){ 
return mStrect; 

public String gctStrcctToXML( X 

if (getSircet( ) = null) return null; 
char [ ] c = getStreet( ).toCharAnay( ); 
StringBuffer sb • new StringBuffcr( ); . 
for (intx » 0; x < dength; X'H-){ 

switch(c(x]){ 

case *>*: 

sbjppcnd(->"); 
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-continued 



break; 
case *<*i 

sb^peadC'ftlt;'0; 

break; 
case *&*: 

sb^pendC&"); 

break; 
case 

8b^pead(*""); 
breaic; 
case 'V*: 

sb^peadC"")* 
bredc; 
de&ult: 
if (CliaracteLisDefuied(c[z])) 
sb.^3peiid(c[z]); 

>^ 

retum'sb.tbStriiig( ^ 

pobHc void MtStieet(Strmg inp){ 
thisjnStreet - bp; 

public void streetFroniXML(Stiiiig ii){ 
setStreet(n); 

} 

public String gptCity( X 
return mGty; 

public String getCityToXML( ){ 

if (getCUy( ) — null) return null; 
char [ ] c = gctCity( ).toCharArray( ); 
StringRuflFer sb » new StiuigBuffei( ^ 
for (int X - 0; x < cJength; x++){ 
switd](c{x]){ 
case •>*: 
Bb.appeDd(*>'0; 
break; 
case '<': 
8b4ippcnd("<'*); 
breiJc; 
case 

sb^peadC'&'^; 

brcsd^ 
case 

ab^^ndC&qnot;"); 
case 'V*: 

8b.append("&qiiot;'7; 
breaks 



if (aiaiactei:i8Defiiied(c[x})) 
abuappeiid(c{x]); 

} 

} 

return ab.toStririg(); 

} 

public void setQty^tring iiip){ 
ibis jnCity - iiip; 

public void cityFroniXML(Stiing n>{ 
8etCity(n>. 

public int getState( ){ 
return mState; 

} 

public String g|BtStateToXML( X 
switch (mState) { 

case AK return "AIC*; 
case AL: return "AL" 
case AR: return "AR' 
case AZ: return "AZ* 

} 

return null; 

public void 8etState(iiit ii^>X 
thisjnState - inp; 

} 
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public void stateFiDinXML(Striiig s>{ 

if (s.equalsCAK'^) mStste » AK; 
else if (s-equalsCVUr^mState - AL; 
else if (s.eqiialsC'AR'0)inState « AR; 
else if (s-equalsCATO^nState - AX; 

} 

public String getPostcode( ){ 
return mPostoode; 

} 

public String giatPostcode1bXML( ){ 

if (getPostcode( ) — null) tetum null; 
char [ ] c - gptPostcode( ).toChaTAiny( ); 
StringBuffer sb o aew StringBuffei( ); 
for (int X - 0; X < cJength; x-H>){ 
5witch(c(xD{ 
case •>': 
6bAppeDd(->"); 
bfeaj^ 
case *<*: 
sb^peodC<*^ 
breidc; 
case *&*: 
abAppeDd(**&'^; 
bredc; 
case 

sb. appeiid(""'7; 

break; 
case '\": 

sb^peadC&qtnt;*^; 

break; 
default: 

if (CharacteLisDefiiied(c{x])) 
sb.Append(c{x]); 

} 

return 8b.toString( ); 

public void setPostcode(StriQg iiq>){ 
thisjnPostoode - inp; 

} 

public void postcodeFroniXML(String n){ 
8etPo8toode(a); 

} 

public int getCountry( ){ 
return mCountry; 

public String getCouatrylbXML( ){ 
switch (mCbuntry){ 

case AD: return "AD"; 
case AE: return "AE"; 
case AF: return "AP* 

} 

return null; 

} 

public void setQ}untry(int inp){ 
thisjnOountry « ii^>; 

} 

public void countryFroinXML(String s){ 

ifi[$.ec[uals("Aiy)) mCountry • AD; 
else if (s.equals(''AE"))mCoiintry - AE; 
else if (s.equal8(''AF"))mCbtmtiy - AP, 
else if (s.equals("AG^)mCountry - AG; 
else if (8.equals(''Ar))mCountry • AI; 

r 

} 

package co1n.veojEdk.dev.5dKix1a.test.Uib; 
import com.veo.vsp.docleLmeta.Documeiit; 
public class AddressSet extends Document { 

public static final String IXX:_TYPE » "address-ser; 
AddressPhysical mAddressFhysical; 
String [ ] mTbIq>bone; 
String [ ] mPax; 
String [ ] m Email; 
String [ ] mintemet; 
public AddressSct( ){ 

super(DOCL-TYPE); 
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this.mA(ldicssPfaysical » new AddressPhysical( ); 
mlblephone « null; 
mFax-null; 
mEniail • nxill; 
mlntemet a mill; 
} 

public AddrcssSct(Stnng doc_type){ 
supei(doc_typc); 

this-xnAddressPhysicai - new Addr68sPhy8ical( ); 
mTclcphoQc " null; 
mFajt » null; 
mEmail - nnll; 
mlntemet a null; 

> 

static public AddressSet initAddies8Set(AddTeBsPhy8ical iAddressPhysical^tring [ ] 
ireleplioiw,Striiig ( ] iFax^String [ ] [£inail,Stnng [ ] ilntcraet){ 
AddressSet obj <> new AddressSet( ^ 

obj.imtializeAll(Addi«S8Phy5ical, iTelephose, iFax, iEoiail, ilntemet); 
return obj; 

public void initializeAll(Addre66PhyBical iAddressPhysical^triog [ ] flbl^honCyStiing [ ] 
iFax^tiing [ ] iEmaii;5tring [ ] i[ntcmct){ 

mAddressPhysical » iAddiessPhysical; 
mTelephoae - flblephone; 
mFax - iFax; 
mEmail iEmaO; 
mlntemet « iLiteraet; 

} 

public AddiessPhystcal getAddiessPhysical( ){ 
return mAddressPhysical; 

} 

public void setAddressPhysical(AddrcssPhysical inp){ 
this, mAddressPhysical » u^; 

} 

public String [ ] gctTblephoQe( ){ 
return ml^lephone; 

public String gptTblephone(iiit index){ 
if (this.mTeIephoDe • null) 

return null; 
if (index >- this.mTblq>faone.lcagth) 

return null; 

if (index <0 && -ittdex> thi8.mTbIephone. length) 
return null; 

if (index >= 0) return this.mTelephone{indext 

return this.mTelephottB[tlii8.mTelephoiie.lengtli * bdex| 

public String [ ] gctTclephoneTbXML( ){ 

String [ ] valArr - getl^lephone( ); 
if (valAir — null) return null; 
String [ ] nvAn ■ new String[valAn.length]; 
for (int z - 0; z < nvArx.lengMi; «++){ 
char [ ] c - valAn{z].toCharArray( ); 
StringBuffer st » new StringBuSer( ); 
StringBuffer sb - new StrittgBuffei< ^ 
for (int X - 0; X < cJenglh; x++){ 

switch(c(x]){ 

case *>': 

sb.appendC&g^*^; 
break; 
case *<': 

sbJ^ypendC<''); 
break; 
case 

sb^appendCftan^;'^; 
break; 
case 

sb.appettdCftquot;'^; 
break; 
case 

sb, appcnd(""'0; 
break; 
default: 

if (Character.isDefi&ed(((x])) 
sb. appcnd(c[x]); 

) 

ttvAfifz] - sb.toString( ); 

> 
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return nvArr, 

public void 8efIblephone(int index, String inp){ 
if (this.m'Iblephonc null){ 
if(indai<0) { 
thiaml^l^bone - new String[l}; 
Uiis.m']n:lephone[0] - inp; 
}else{ 

tIus.in'Iblq)hone - new String[index + 1^ 
Uus.m'Iblqphone[index] inp; 

} 

} else if (index < 0) { 

String [ ] newTblepbooe =• new String[this.in'Iblephone.lei^t]i -t- 1]; 
java.Iang.Systein.arTaycopy((Ofaject)mTelephoae, 0, 
(Object)neWraqjhon^ 0, this.mTel^honcleiig^); 

ncWrclcphoac(ncwTtlcphonc.lcngth - 1] •» inpi 
mTelephone » newTblephone; 
} else if (index >« this.mTelephone.lengtfa){ 

String [ ] newIfcIq>li6DC - new String[indn ■¥ 1]; 
java.Iang.Sy5teni.arraycx)py((C%iject)in'Iblephoae, 0, 
(Object)newTblq)hone, 0, this.mTelephone.length); 

newTclcphoae[iadex] - inp; 
ml^lephone » newlblephone; 
}elBe{ 

tlus.mTblephotte[ittdex] «■ ii^; 

} 

} 

public void KtTclephone(String [ ] inp){ 
this.mTblephoiie • inp; 

public void telephoneFroniXML(String n){ 
seilbIeplione(-l, n); 

} 

public String [ ] getFBx( ){ 
return mFax; 

} 

public String getFax(int index){ 
if(tIiisjnFax «=« null) 

return null; 
if(index >— this.mFkx.leagth) 

return null; 
if (index < 0 &&. -indcx> this.mFax.Iength) 

return null; 
if (index >a 0) return this.mFax[LQdex]; 
return this.mFax[this.mFax.length -i- index]; 

public String [ ] gclFwO-oXMU ){ 

String [ ] valArr = gctFai( ); 
if (valArr ~ null) return null; 
String [ ] rrvArr =■ new String[valArr.Iength]; 
for (int 2 = 0; z < nvArLlength; z++){ 
char [ ] c - valAnfzJtoChar Array ( ); 
StringBuffcr »t - new StringBuffar( ); 
SlringBufTer sb = new ScringBuffier( ); 
for (int X » 0; X < clength; 

switch(c{x]){ 

case 

sbjippcnd(->*0; 

brealc; 
case *<': 

sb.append(-<'*); 

break; 
case '&*: 

sb.appettd(*&anip;*'); 

breaJc; 
case 

sbjippendCftcpJot;"); 
break; 
case 

sb.append("&<piol,*'); 
break; 
default: 
if (Character.isDefined(c(x])) 
6b.nppend(c{x]); 

} 

> 

nvAnfz] - 6b.toString( ); 
} 

return nvArr; 
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public void setF^z^t index, String tnp){ 
ifi[this.inFax — null){ 
if(mdex < 0) { 
this.mFax » new String[l^ 
Uus.inFax{0] - iitp; 
}elsc{ 

this.mRix *> new String[index -f 1]; 
this.mFax[index] - inp; 

} 

} else if (index < 0) { 

String [ ] newFaz - new StnDg[tlus.iiiFBx.length -h 1]; 
java.!ang.Systcm.arraycopy((Object)inFax, 0, (Object)newFa]^ 0, 

this.inFaxJengt]i); 

newFax(DewFax. length - 1] - inp; 
mFax " DcwFaz; 
} else if (index Lhis.mFax.length){ 

String [ ] newFax - new Stnng[Lndex + 1]; 
javaJBng.Sysleni.arraycopy((Object)inFax, 0, (Object)tte«i''a]^ 0, 

this mPaz length); 

newFax[index] - inp; 
mFax - newF&x 
}el8c{ 

t]us.mFaK[inde3c] - inp; 

) 

} 

pablic void setFax(Stiing [ ] inp){ 
thia^mFax * Lop; 

} 

public void &xFroinXML(String n){ 
8«tFax(-l, n); 

} 

pablic String [ ] gpt£mail( ){ 
retun mEmail; 

} 

pablic Sixing gietEaiail(int index){ 
if (this.mEniail - null) 

return null; 
if (index >« this.mEmail.length) 

return null; 

if (index < 0 && -tiidex> thi8.mEmail.!cngth) 

return null; 
if (index >- 0) return thiB.mPfnail[indext 
return this.&nail[this.EmaiIienglh -t- index^ 

} 

public String [ ] getEmainbXML( ){ 

String [ ] valArr » getEniail( ); 
if (valArr = null) return nuU; 
Stiing [ ] nvAjT - new StringfvalArr.length]; 
for (iot z « 0; z < nvArtlcngth; z-m>)( 
char [ ] c - valAxf[z].toCharAiray( ); 
StiingBuffer st - new StringBuffer( ); 
StringBuffer sb - new StrtngBujSei( ); 
for (int X « 0, X < clength; x++){ 
switch(c(x]){ 
case *>': 
sb. appendC>**); 
break; 
case *<': 

sb.appendC&ll;'*); 
break; 
case 

8bjppeQdC&aiiq);*0; 
bresJc; 
case 

sb. appendC""); 
break; 
case 

sb.appCQd(*'"'Ot 
break; 
default: 

if (Chaiacter.isDefitted(((x])) 
sbJi)pend(c[x]>; 

} 

} 

nvAnfz] - sb.loStrittg( ); 

} 

return nvArr; 
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public void setEinail(iat index* String inp){ 
ifi(tbis.inEmail null) { 
if(index < 0) { 

ihis.mEmail « new String[l]; 

tliis.mEmaillO] ■> inp; 

}C!8C{ 

thi8.mEaiail = new Strii^index -f 1]; 
tlu8.mEmBilI index] a inp; 

} eke if (index < 0) { 

String [ ] newEmail •» new String[d)is.mEmaLl.leng|h + 1^ 
java.lang.Systan.arraycopy((Object^EniaU, 0, (Object}newEmafl, 0, 
diis.mEmail.length); 

newEmaiI[ncwEmaiLlength - 1] - inp; 
mEmai] • ncwEmail; 
} else if (index >» tlus.niEmflil.lcngth){ 

String [ ] newEmail «» new Strin^index + 

java.lang.System.arraycopy((Object)mEniai], 0, (Object)newEmafl, 0, 
thi5.inEmaiI.lcngtfi); 

newEinail[indez] - inp; 
mEmai] — newEmail; 
}elBe{ 

this.mEmail[iadex] « inp; 

} 

} 

public void setEfflail(String [ ] aipy{ 
thisjnEmail > isj^ 

public void emailFiomXML(String n){ 
setEmail(>l, n); 

} 

public String [ ] getlntemet( ){ 
return mlntemet; 

} 

public String gctlntemet(int indcx){ 
if (this.mlntemet == null) 

return null; 
if (index >« this.mlntcrneLlength) 

return null; 

if (index < 0 && -index > this.ni[ntemet.Iength) 

return null; 
if (index >• 0) return this.mlntemet{iadex]; 
return thi8.mIotemet[thi8.mIntemetJengUi + index]; 

public String [ ] getIntemetToXML( ){ 
String [ ] valArr - gBtInteiDet( ); 
if (valArr null) return null; 
String [ ] nvArr = new String[valArr.length]; 
for (int z - 0; z < nvArr.length; Z4^){ 
char [ ] c B valAn{z].toCharArray( ); 
StringBuffer st i* new StringBufiEer( ); 
StringBuffer sb - new StringBuffei< >, 
for (int X - X < cJengMi; x4+){ 
switch(c[x]){ 
case '>': 
sb.appendC&g^"); 
bitaJe; 
case •<*: 

sbJippcndC<"); 
break; 
case 

sb^pendCftamp;"); 
breiJc; 
case 

sbjippendC""); 
break; 
case 

Bbjippend('ftquot;"); 
break; 
default: 
if (Cbaracter.isDefined(c[x])) 
8bJ^)pcnd(c(x]); 

} 

} 

nvAnfz] sb.toStimg( ); 
} 

return nvArr; 

} 

public void setlntemet(int index. String inp){ 
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if (this.mli]teni€t «= null){ 
if(iiidez < 0) { 
thi8.m[ntemet - new StringJ]^ 

thi5.mlntcmet[0] = inp; 
}else{ 

this.mlntemet new Stiing[u]dex -i- 1]; 
this.in[ntemet[imlex] ■> inp; 

} 

} else if (index < 0) { 

String [ ] Dcwlntcmet = new String[this.mIntcmeLlcngtb + Ij 
java.Iang.Systein.arTaycopy((Object)mInteniet, 0, (Object)newlQtemet, 
0, thisjnlBtenieLleiigth); 

ncwlnterQctCiiewIntemctlength - 1] * inp; 
mlntemet <> newlntemet; 
} else if (index >- Uiis.mtntemet,leiigth){ 

String [ ] newlntemet • new String[indrac -i- 1^ 
java.lang.System.amyoopy((Object)mInteinet, 0, (Object)iiewlQtemet, 
0, thisjnInterneLlength); 

newLitemct[inda] > tap; 
mloteniet - nev^teniet; 
}elBe{ 

tlus.oiIntentet[i&dex] » mp; 

^ } 

public void aetInteTnet(String [ ] ii^){ 
this.mlntemet » inp; 

} 

pablic void intemetFroinXML(String n){ 
setlnieinet(-l, c); 

} 

} 

package com.veo jdk.devjschema.test.hlib; 
impoft com.veo.vsp.doclet.meta.Docuinent; 
public class Business extends Party { 

public static final String DOC— TYPE = "business'*; 
String aBusinessNumber, 
pablic Busines8( ){ 

snp6i(DOC_TYPE); 
aBusinessNunber m new Siring^ ^ 

pablic BusiDe88(String doc_type){ 

$oper(doc_type); 
aBusinessNumber - new String( ^ 
} 

static pablic Business initBusiness(String iBusinessNumber,String [ ] 
iPaityName^AddressSet iAddresBSet){ 

Business obj • new Business( ); 

obj.imtiaIizeAU^BusinessNasiber> iPartyName, iAddressSet); 
return obj; 

} 

pablic void initiaUzeAllCString iBusiiie8sNumbei;String [ ] iPaityNameAddressSet 
iAddie8sSet){ 

ftBusineasNumber •> iBusineasNomber, 
8iipeLinilializeAlI(iPutyName, iAddressSet); 

} 

public String gptBu8inessNuniber( ){ 
return aBusinessNumber; 

} 

pablic String gptBusinessNumberlbXMLC ){ 

if (getBusinessNumberC ) *» null) return null; 
char [ 1 c «» getBisinessNumber( ).toCharAnBy( ); 
StringBuffer sb - new StringBuffer( >, 
for (int z - 0; X < clength; x-h>){ 

8witdi(c(x]){ 

case *>*: 

sb.appcnd("&gl;*^; 
break; 
case '<': 

sb. appcnd("<**); 
break; 
case '&*: 

sb3ppcad(**&ac]p;"); 

brcsJc; 
case 

sbj^^nd(**&quat;*^ 
break; 
case T: 

sbjq>pend(**ftquot;*0; 
break; 
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default: 

if (ChaTacter.isDefiiied(((x])} 
Bbiippeiid(c(x]); 

} 

> 

return Bb.toStnflg( ); 

} 

public void setBusinessNiunber(String inp){ 
thts.aBusinessN'uinber - inp; 

public void businessNumberFramXMIXString 
8etBusisessNuinbei(n); 

} 

} 

import com.veo.vsp.docIetmeta.Document; 
public class Party extends Document{ 

public static final String DOC_TYPE ■ "p^'Y**! 
String [ ] mPartyName; 
AddressSet mAddfcssSet; 
public Faity( ){ 

supci(DOC_TYPE); 
mPaityName - new Stringfoj; 

this.inAddicssSet « new AddrcssSct( ); 

} 

public Party (String doc_type){ 

sapcr(doc_typc); 
mPartyName = new Strin^O]; 

this.mAddrcs9Sct » new AddrcssSet( ); 

} 

static public Party initParty^String [ ] iPartyName^AddressSet iAddressSet){ 
Party obj - new Pbrty( ); 
obj.initializeAlI(iRutyNaine, iAddiessSet); 

return obj; 

} 

public void initudizcAll (String [ ] iPartyNamc,AddressSet iAddressSet){ 
mPartyName « il^ityName; 
mAddiessSet » iAddressSet; 

} 

public String [ ] getPartyName( ){ 
return mPartyNamB; 

} 

public String gptPartyName(int index){ 
if (this.mPartyName — null) 

return null; 
if (index >«• this.mPartyName.length) 

return null 

if ^dex < 0 &8t -indeio this.mPartyName Jength) 
return null; 

if(index >- 0) return lhisjnPart^ame[index]; 

return thi$.mPartyName[this.mPartyName.length -i- index]; 

} 

public String [ ] getPartyNameToXML( X 

String [ ) valAn - getPartyName( ); 
if (valArr «- null) return null; 
String [ ] nvAn » new String[valArr.length]; 
for (int z - 0; z < nvAn.lcng^; z++){ 
char [ J c = nvAntz].toaiaiAnay( ); 
StringBuffcr st = new StringBuffcr( ); 
StringBufFer sb - new StringBuffci( j; 
for (int X » O, X < dength; x-m-H 

switcfa(c(x]){ 

case *>• 

8bi^)pcnd(->0; 

break; 
case *<': 

sb.appcndC&ll;'^; 

break; 
case *&.*: 

sbjtppcndC&"); 

break; 
case 

sbjippcndC*""); 
break; 
case 

sbj^jpendCakquot;*"); 
break; 
default: 
if (Character.isDcfined(c{xD) 
sb.append(c(x]^. 
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} 

} 

nvAnfz] - sb.U>Struig( ); 

} 

return nvAir; 

public void sctP&rtyNaine(int index. String iiq>X 
if (this.mPartyName «=- null) { 
if(inde3i < 0) { 
this.mPaityNamc = new Stnng[l]; 
this.mPaityName[0] » inp; 
}el8e{ 

tlus.mPaityNamc » acw String[index + 1]; 
this.mPartyNamef index] - inp; 

} else if (index < 0) { 

String [ ] newPaityName «> new String[this.mPartyName.leiigth + 1]; 
java.Iang.Systan.arraycopy((Object)inPartyName, 0> 
(Object)ne«^ar^Kame, 0, Uiis.mFnrtyNamc.length); 
newPartyName{newPart)tfame.length - 1] » inp; 
ml^utyName - newPaityName; 

} else if (index >- Uiis,mPartyName.Icngth){ 

String [ ] oewPartyName - new String[index 1]; 
java.lang.$ystem.anaycopy((Ob|ect)mFaityName, 0, 
(Object)newPartyName, 0, Uiia.mPnityNanie.length); 

newPaityNam^indcx] - inp; 
mPartyName newPaityName; 
)c!ac{ 

tlus.mP&rQrNanie[index] >» bsp; 

} ^ 

public void setPartyNaine(String [ ] uip){ 
this.mPbrt^ame » inp; 

} 

public void Pait^ameFh>iiiXML(String n){ 
setPartyName(-l, n); 

public AddressSct getAddiessSet( ){ 
return mAddressSet; 

} 

public void 8etAddressSet(AddressSet ixq>X 
thisjiAddressSet » in^ 

} 

} 

padcage com.veojcdk.dev^hema.Cest.blib; 
import com.veo.v^.doclet^etB.Document; 
public class Person extends Party { 

public static final String DOCL-TYPE » '^ersott't 
String aSSN; 
public Person( ){ 

$opcr(IX)C_TyPE); 
aSSN - null; 
} 

public PersoD(String doGL.type){ 

soper(doc^type); 
aSSN - null; 
} 

static public Person initPeison(String iSSN,String [ ] iPartyNanie,AddressSct 
iAddieasSetX 

Person obj «» new Peison( ); 
obj.imiializeAU(iSSN, iPaityName, iAddressSet^ 
return obj; 

} 

public void inittalizeAll(Stimg iSSN,String [ ] iPaityName^ilddressSct iAddiessSet){ 
aSSN - iSSN; 

8upeLinitializeAll^PaityName» iAddicssSet); 

} 

public String gctSSN( ){ 
return aSSN; 

} 

public String gctSSmbXML( ){ 

if (gctSSN( ) °- null) return null; 
char [ ] c » getSSN( ).toChaiArray( ); 
StiingBuSer sb - new StringBuffer( ); 
for (int X ■ 0; X < cJength; 

s«dtdi(c(x]){ 

case *>*: 

sbjippend("&gh*0; 
breij^ 
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case '<*: 

EbJippendC<"^ 
case 

sb^pead(~&'^ 
break; 
case 

sb^peodC"''); 

bruik; 
case *\": 

sb^peadC""); 

bre^Jq 
default: 

if (Cbaiacter.isDefiited(c(x])) 
8bjippcnd(clx3); 

} 

return sKtoString^ ); 

public void setSSN(Strmg tnp){ 
this.aSSN * inp; 

} 

public void sSNProaiXML(Stiing ii){ 
setSSNCn^ 

} ^ 

package coin.veojtdk.dev.schema.test.blib; 
import coin.veo.v^.dodeLmeta.Docuineiit; 
public dass Proto^peService extends Document{ 

public static final String DOC_TYPE = "prototypcscrvice"; 
String mServiccName; 
String [ ] mServiceTbnns; 
String [ ] mServiceLocation; 
ServiceOperation [ ] mServioeOperBtion; 
public PrototypcScrvicc( ){ 

super(DOC_.TYPE); 
mSeiviceName - new String( ); 
mScrvicelbrms » new Striag[0]; 
mServiceLocation » new String[0]; 

thisjnServiceOperation — new ServiccOperation[0^ 

public PiototypeService(5tiing doc_type){ 

6upcr(doc_typc); 
mScrviceNanw » new String( ); 
mServicelbnns a new String[0]; 
mSciviceLocatiott » new &riug(0]; 

thisjnServiceOpemtiou ■» new SeiviceOperat£on[0l 

} 

static public PrototypeService initPn>totypeService(Strittg iServiceName^tring [ ] 
iScfviceTermsyStiittg [ ] iServioeLocationyServioeC^ration [ ] iServiceOpentiou){ 

PrototypeSeivioe obj •> new PTototypeSeivice( ); 

objinitialEzeAll(iServioeNasw, iServioeT^nns, iSeiviceLocation, 
iSeiviocppeRition]^ 

rttuiii obj; 

} 

public void initializeAll(Stiing iServiceName^String [ ] iS6rvioelbnns,StrLttg ( ] 
iSemceLocation^SeiviceOperation [ ] iServiceOperation){ 
mSeiviceNaine » iServiceName; 
mServiceTenns - iServiccTeims; 
mServiceLocation - iServiccLocatioa; 
mSeiviceOperation - iServiceOperation; 

} 

public String g!etSeiviceName( ){ 
return mServioeName; 

} 

public String gctScrviceNamelbXMLC ){ 

if (getServioeName( ) =■ null) rebuu null; 
char [ ] c - gptSeiviceName( ).toCharArray( ); 
StringBuffer sb - new Sliuig3u£rer( ); 
for (int X » 0; z < clength; x+*){ 

swLtch(c(x]){ 

case •>*: 

sbjippcud(-&gfc"); 
break; 
case '<': 

sb.append(-<"); 
break; 
case *&^ 

sb.a(^Qd("&"); 
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break; 
cue 

sbjippendC"'^; 
break; 
case *V': 

Bbuippcnd(""*0; 
break; 
default: 

i£ (ChBTactei.isDeaiie<l(c[x])) 
8bj{)pcnd(c(x]); 

} 

} 

return sb.toString( ); 

} 

public void setServiceName(StiLiig iiip){ 
tliisjnServtceNaine • iap; 

} 

public void seiviceNameFioinXML(String a){ 
setSemceNaine(n); 

public String [ ] getSeiytcelbnii^ ){ 
return mScrviccTbrms; 

} 

public String getSeiviceTVnn8(int index){ 
if (this.mServiceTeni]S «» null) 

return null; 

if (index >« this.mSeivioeTbrmsJength) 
return null; 

if (index < 0 &ft -iadex>tbisjnService'I^nns.length) 
return null; 

if (index >• 0) return tfais-mSeivicelfcRn^iiKlex]; 

return t]iis.mSeivioefI%niis[thisjnService'Ibrnis.length + index]; 

} 

public String [ ] getSeivicelbnnsToXNfl^ ){ 
String [ ] valAn - gctScrvice'Itrms( ); 
if (valArr «» null) return null; 
String [ ] QvArr - new Stnng[valArr.leng|th^ 
for (int z = 0; z < nvArr.lcngth; z-»-+){ 
chai [ ] c = valAn(z].toCbarAiTay( ); 
StringBuSer st - new StringBu&r( ); 
String3ufier ab - new StringPufiei< ); 
for (int X - 0; X < clength; x4+){ 

switch(c{x]){ 

case •>': 

sbiCTCttdC>"); 

break; 
case *<': 

sb.append(*&It;"); 

break; 
case *&*: 

sb.appeiid(*&*^ 
break; 
case 

$b.appeadC'ftquot;*0; 
break; 
case 

sb.appendC'&quol;*'); 
biesjc; 
default: 

if (Chafacter.isDelined(c(xD> 
8b.append(c[x]); 

} 

} 

nvAn[z] « sb.toStrmg( ); 
} 

return nvAir, 

} 

public void setServicelbnns^t indcac. String inp){ 
if (this.mSeivicelVzins i» nuU){ 
if(index < 0) { 
this.mServiceTerais - new String[l]; 

this.mSciviceTcnns[0} = iiq>; 

>*!".^ 

Chis.inServiceTenns - new Striag[index + 1]; 
this jnSeivkeTerms[iiidc3c] ■ inp; 

} elae if (index < 0) { 

String [ ] oewServioeTbnns - new String[this.mServiceTenns.length -i- 
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java.laogpSystem.arraycopy((Object)mService'I%nns; 0, 
(Object)newServicelbnns, 0, this.mSeivice'rbiiiis.leiigth); 

aewSemcel^rm^newSeiviceTBnnsjengtb - 1] - inp; 

mScrviccltrms = ncwScmccltrms; 
} else if (index >= Uiis.mServiceTenns.leiigth){ 

String ( ] newScrvicelinna - new String[index + Ij; 

java.lamg>Systemjmycopy((Ob}ect)inSciviceTcnns, 0, 
(Object)newService'I%nn$, 0, this.mSeivicel^nm.length); 

aewSeivtoeTenns[uidex] - iap; 

mScrvicc'Ibnns ■ newSciviceTbims, 
}cke{ 

thi8.niServioe'Ibni]8[iiide]i] - ii^, 

} 

} 

public void setServiceTerms(Stiing [ ] mp){ 
thisjnScrvicclbnns = inp; 

} 

public void s«rviceTenmFiomXML(Strii]g n){ 
setServicelbnnsC-l, njn 

} 

public String [ ] g^tSeiviceLocatt0n( ){ 
return mScrviccLocation; 

} 

public Stiing g^tSeivtceLocattDii(int iiidex){ 
if (this.mServiccLocation « ntill) 

return null; 
if (index >« this.inSeivioeLocationJength) 

return null; 

if (index < 0 Aft -udex>tliisjnSeiviceLocation.leng|th) 
return null; 

if (index >- 0) return thts.mSefviceLocation[index]; 

return this.mSeiviceLocatioii[thisjnSeiviceLocation.length -i- index); 

> . . 

public String [ ] getSeiviceLocationToXML( ){ 
Stiing ( ] valArr «■ gctServiceLocation( ); 
if (valAir = null) return null; 
String [ ] nvAir - new StringfvalAriength]; 
for (int z = 0; z < nvArr.lcngth; z++){ 
char [ ] c = valArT(z].toCharArTay( ); 
StringBuffcr st - new StringBuflBei< ); 
StringBuffer sb - new StiingBufEeK ); 
for (int X - 0; X < clength; x++){ 
Bwitch(c(x]){ 
case '>': 
sb^pend(-&g^"); 
break; 
case *<': 

sb^pend(-&ll;"); 
break; 
case 

sb.append("&"); 

breajc; 
case 

sb^pendC'ftquot;*'); 
break; 
* case *'*: 

sb^pendC""); 
bre^; 
default: 

if (Chaiaaer.isDeflned(c[x])) 
sbjippeiid(c[x]); 

} 

} 

nvAnf z] « sb.toStrtttg( ^ 
} 

return nvArr; 

} 

public void BetServioeLocation^ index. String inp){ 
if (this.niSeiviceLocBtton » null) { 
if(index -c 0) { 
tluB.mServiceLocation - new Stringf 1} 
this.mScrviccLcxatioiiO] ■■ inp; 
}else{ 

tlus.mServiceLocation - new Stiing[index -i- 1^ 
this.mSeiyiceLocation[index] - inp; 

} 

} eke if (index < 0) { 

String [ ] DcwServiceLocation ■ new 
String[thi&mServiceLocationJength -t- 1]; 
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java.laiig.System3iTaycopy((Object)inServiceLocatioD, 0, 
(Object)newServiceIjocatioii, 0, UiisjnSeiviceLocatioaJeiigMiX 

newSeiviceLocatioD[newSeiviceLocatioa.leagth - 1] - inp; 

mServiccLocatioii « newSciviceLocatioQ; 
} else if (index > lhi5.mServiceLocatioii.Iengtb){ 

String [ ] newSeiviceLocation - new String{index + Ij; 

java.lang.System.arTaycopy((Objcct)mSeiviceLocation» 0, 
(Object)newServiceLocatioii, 0, thisjDServiceLocation.length); 

newSeivtceLocatlon[indez] - inp; 

mServiccLocadoa » newSeivtccLoaitton: 
}elsc{ 

thiB.inServioeLocatioii(index] - inp; 

} 

} 

public void setServiceLocationOString [ ] inp){ 
thisjnServiceLocation = inp; 

public void serviceLocationFioariXML(String a){ 
setServiceLocation(-l, n); 

} 

public SennceOperadon [ ] getServioeOperation( ){ 
return mServioeO|Mnition; 

} 

public ServiceOperation getServioeOpeiatk»i(int index){ 
if (this.inScrviccOpemtion — null) 

return null; 
if (index >» this.niSeivioeOperetionJength) 

return null; 

if (index < 0 && -index >« this.inServiceOpeiation.length) 
letum null; 

a (index >- 0) return this.n)SeiviceOpemtion[isd«]; 

return this.mServiceOpeiBtion[this.inSeiviceOperatioii.lengtb -i- index]; 

} 

public void setServiceOperation(int index, ServiceOperation inp){ 
if (this-mServiccOpcration = null){ 
if(index < 0) { 
this.mServiceOperatbn - new ServiceOperation[]|^ 
tIus.mSciviceC^ration[0] - iop; 
}el«{ 

tbis.mServiceC>peration - new ServiceOperation[ index + 1^ 
tluB.mServioeOperatiDn[indcx] - iap; 

} 

} else if (index < 0) { 

ScrviocOpcratioQ [ ] ncwServiceOperation new 
ServiceOperationfthis.aiServiceOperadoiLlength +■ 1% 

java.lang.5ystem.arrBycopy((Object)mServiceOperadon, 0, 
(Object)newServiceOperfttion« 0» this.mServiceOpeiadonJengtb); 

newSeiVLceOperadonfnewseiVLceOperadon. length 1] » inp; 

mScrviceOperadon - DewServiceOperadon; 
} else if (index tlus.inServiceOpetsdoii.lengtb){ 

ServiceOperadoa [ ] newServiceOpeiadcm « new 
Service(^peTadoa{ index -f 1^ 

java.lang.Systcm.arraycopy((Object)mSeiviceOpemdon, 0, 
(Object)newServiceOperadon, 0, this.mSeiviceOperadoaiength); 

newServiceC^>eration[index] ■* isp\ 

mScrviceOpeiatbn - oewScxviceOperation; 
}elsc{ 

this.mServkxC^enitioii[iiidex] <■ inp; 

} 

} 

public void setServiceOpeiaUon(ServioeOpeiation [ ] iiip){ 
thisjnServiceOpemdon • inp; 

} 

} 

package com.veojidk.devjschema.tesLHib; 
import com.vco.v^.doclet,mcta.Documcnt; 
public class Service extends Document{ 

public atadc Enal String DOC_TYPE - "service*'; 

String mServioeName; 

String mServioeLocation; 

ServiceOperadon [ ] mSeivicBC^ratbtt; 

String mServioeTcrms; 

public Service( ){ 

super(DOC;_TYPE>, 

mSciviceName - ikw String( ); 

mSeiviceLocation - new Strjb:ig( ); 

thisjnServiceOpeiBdoQ - new ServioeOperadon[0[| 

mScivice'RnttS - new Striag( ); 

} 
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public Seivice(Striiig doc_type){ 

supcr(doc_typeX 
oiSeiviceName - new &iiiig( ); 
oiSeiviceLocation » new StriiigC ); 

UiisjnServiceOperation » new SeiviceOpenittoii[0j 
n^eiviccTbrau - new String( ); 

} 

static public Sendee initServics(Stnng iServioeName^tring 
iSeiviceLocatio&ySeiviceOperation [ ] iServiceOperation,5tring iScrviceTenna){ 
Service obj = new Scrvicc( ); 

obj .inf rial i7f. All(iSeryiocName, iServiceLocation, iServiceOpeiation, 
iServiceTenns]^ 

return obj; 

} 

public void initialize All(String iServiceName,Stiittg iServiceLocBtion^ervneQperation 
[ ] iSemoeOpcratioQ^tring iScrvicc'Ibnns){ 

mServiceName « iServiceName; 
OiSeiviceLocation - iServiceLocation; 
mSeiviceOperation - iServiceOperation; 
mSeivice'I^nns - iSeiviceTBnns; 

public String gctScrviccName( ){ 
return mServioeName; 

public String getSefviceNameToXML( ){ 

if (getServioeName( ) =■ null) retura mill; 
char [ ] c *> gBtServiceNaaie( ).toCharAnay( ); 
StringBuffer sb - new StiuigaufiEer( ); 
for (int x» 0; X < cJength; Xi-i'){ 

switcfa(c(x]){ 

case •>': 

sb. appendC>"); 

break; 
case '<': 

5b^pcnd(-&U;"); 
case 

sb.appeadC&'^; 
bresJc; 
case 

sb. appendC"'^; 

brealc; 
case 'V*: 

sb jippend('*"**); 

break; 
default: 

if (Oiaracter.isOefiiKd(c(x])) 
sb.append(c(x]); 

} 

} 

return sbitDStringC ^ 

} 

public void aetSeTvioeName(String inpX 
this jnServiceName » inm 

} 

public void scrviceNameFromXML(Striag n){ 
setSaviccNainc(n); 

public String getServiceLocatioa( ){ 
return mServiceLcxaticm; 

} 

public String g^rviceLocationlbXMLC ){ 
if (getServioeLocation( ) null) return null; 
char [ ] c a gptServiceIi>cation( ).toCharArray( ); 
StringBuffer sb — new StringBufirer( ); 
for ^t X a 0; X < clength; x++){ 
switcfa(c[x]){ 
case '>': 
sbAppcndC>**); 
break; 



5b4ippcnd(-&U;"); 
break; 
case 

sb.B(^nd(**&anip;*0; 
break; 
case •": 

&b jappcnd(''"">, 
brudc; 
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case 'V*: 

sbJippendCAquot;*^; 

default: 
if (Character.isDeaaed(c(x])) 
8biippeiid(c(3i]); 

} 

} 

return 8b.toStriog( ); 

} 

pablic void setServiceLocationOStiuig mp){ 
thisjnSemceLoc&tion - inp; 

pablic void serviceLocationFioiDXMI<Strisg d){ 
8etServiceLocatioii(n); 

} 

public SeiviceC^ratiott [ ] ^tServiceOpentioa( ){ 
return mServiceOperatioa; 

public SeiviceOperation getServiceOperation(int index)! 
if (this.mServiceOperation — — null) 
return null; 

if (index >« this.mServiceOperationJengtb) 
return null; 

if (index < 0 &8t -index > t]i^.mServiceOpeiation.lengtIi) 
return null; 

if (index >«■ 0) return this.niServiccC^ration[ index]; 

return tliis.mServiceOperation{tbis.mSeivicc0^ration.lcngth > index]; 

} 

pablic void 8etSeTviceOperatiott(int index, ServiceOperation ii^){ 
if (this.mServiceOperation — null) { 
if (index < 0) { 

this.mSeiviceOperation » new ServiceOperation{l|t 
this.mServiceC^ntion[0] - ii^; 
}else{ 

tlus.mServiceOperBtton - new ServiceOpention(index + 1^ 
thiB.mSeiviceOperBtion(inde3c] • iap; 

} 

} else if (index < 0) { 

ServioeOperation [ ] newServiceOperation - new 
ServiceOp6ration[tfais.DiServiceOpcration.lengtli + 1]; 

java.lang.System.arraycopy((Object)mServiceOpemtion, 0. 
(Object)newServiceOperation, 0, this.mServiceOperationJength); 

ncwScrviccOpcration[ncwScrviceOperatioaJengtli - 1] • inp; 

mServiceOperation » newServiceOperation; 
} else if (index >- this.mServiceOperatioalengUi){ 

ServkxOperatioa I ] newServiceOperation = new 
ServiceOperation[index *■ 1^ 

java.Iang.System .arraycopy ((Object)mScrviceOperation, 0, 
(Object)newServiceOperation, 0, this-mServiceOperationiesgtb); 

aewSeivi»Opeiation(index] «• iap; 

mSeiviceOpefation * newServiceOperation; 
}else{ 

tlus.inSeivioeOperation[index] » inp; 

} 

public void setServiceOperation(ServiceOpeiatic»i [ ] inp){ 
thisjnServiceOperation > ii^ 

pablic String getServtceTbnns( ){ 
retuni mServioelbrms; 

} 

public String gdSeiviceTbniislbXML( ){ 

if (getServioel^m^ ) — null) return noil; 
cbar [ ] c - getSciviceTferms( ).toaiarArray( ); 
StringBuScr sb » new Stiing3u£fer( ); 
for (int X B 0; X < cjength; x-i~f){ 

8witch(c(x]){ 

case *>*: 

sbjppcnd(->"); 
case *<': 

sbjippead(~<**); 

breaiq 
case *&': 

sb.appendCftamp;'^ 

break; 
case "*: 

sb^pendC""); 
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break; 
case *\": 

8b^pend(*""); 

default: 
if (Character.isDcfin«i(c(x])) 
sb.Bppeiid(c(x]); 

} 

} 

return sb.toString( ); 

public void 8etSeiviceTenns(Stiing iiip){ 
thisjnScivicelbnns ° inp; 

} 

public void semceTennsFiomXML(Stnng n){ 
setScTvicelbnns(n); 

} 

} 

package com.veojidk.dev^heina.test.Uib; 
import coii].veo.v^.docleuneta.Docuinent; 
public class ServioeOperation extends Dooiinejit{ 

public static final String DOC_TYPE - "servioe.opeiatioa''; 
String ciServiceOpeiationName;. 
String mServiceOpeiationLocation; 
String mServiceOperationlnput; 
String mScrviceOpcialionOntput; 
public S«rviceOperation( ){ 

8npcr(DOC_TYPE); 
mSeiviceC^rationName - new S(iing( ); 
mSeivice(^i«ttonLocation - new String( ); 
mServiceOperationliiput - new String( ^ 
mSeiviceOperationOuqiat «> new Stiing( ); 
} 

public ServiceOperation(String doc__type){ 

supct(doc_typc); 
mServiceOperatiooName » new Stiing( ); 
mServiceOperationLocation - new String( ); 
mServiceC^rationli^Tut «> new String( ); 
mSeiviceOperationOu^t - new String( ); 

static public ServiccOperation initServiceOperation(St7ing 
iServiceOperationName^String iServioeOperatiottLocation^Stfing iServiceOpeiationlnput^trii^ 
iSeiviceOperationOutput){ 

ServiccOperation obj «• new ServiccOpcratioa( ); 

obj.LnitializeAll(iServioBOperationNanie, iSeiviceOperationLocation, 
iSeiviceOperationlnput, iSeivioeOpentionOu^ntt); 

return obj; 

} 

public void initializeAlI(String iServiceOperatiottName,String 
ServiceOperationLocation^String iServiceOperationliiput^tring iServiceOperationOutputX 
mSeiviceOperatiottNaine • iSeivioeOperationName; 
mSeiviceOperationl ocation > iServkeOperationLocation; 
mSeiviceOperationlnpat - iServioeOpeiationlnput; 
mServiceOperationOutpnt - iSenriceOpeiationOutput; 

} 

public String gctScrviccOperatioaName( ){ 
return mServiceOperatiooNajiie; 

} 

public String getSeiviceOperationNameToXML( ){ 

if (gciServiceOpcrationName( ) = null) return null; 
char [ ] c = getScrviccC^rationName( ).toClBrArray( ); 
StringBufifer sb - new StringBufTerC ); 
for (im X » 0; X < clength; x++X 

switch(c[x]){ 

case *>': 

sbappcnd('*&g^;'>, 
break; 
case *<': 

$bjippcndC*&ll;"); 
break; 
case 

sbjippendC&"); 
break; 
case 

sb. append(*'6kquDt;"); 
break; 
case '\": 

sb. appendC""); 
break; 
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default: 
if (aiancter.isDefined(c(z])) 
sbJ^)peIId(c(x]); 

} 

} 

return 8b.toStniig( ); 

} 

pnblic void setServiceOpeiationNasie(Strijig iiip){ 
thisjnServiceOperatioaNaine - inp; 

pablic void serviceOperatioiiNiameFramXML(String a){ 
8etSemceOpeiationNaine(a); 

pablic String gaSeiviceOperationT nnirtnn( ){ 
return mSeivioeC^eratioaLocation; 

paUic String gptSeiviceOperatioaLcKationTQXML( ){ 

if (getServioeOperationLocation( ) null) return null; 
char [ ] c - gptSarviceOperationLocation( ).toCharArray( ); 
StringBuffer sb - new StringBuffeiC ); 
for X - O, X < cJen^h; 

8witch(c(x]){ 

case *>*: 

sb4q>pead(-&g^;*0; 
bredc; 
case *<*: 

sb^pend(*ait;"); 
break; 
case 

sb^pend(*&"); 
breai^ 
case 

Kb^pendC"*'); 
breaJc; 
case 'V: 

Kb. appendC""); 
break; 
default: 
if (Character.isDefined(c{z])) 
sb.appeDd(c(x]); 

} 

return 6b.toString( ); 

} 

pablic void setServiceOpeiationLocatioa(StriDg iq>){ 
thisjnServiceOpeiationLocation 

} 

public void seiviceOperattonLocationFroinXML(Stiing ii){ 
setSemoeOpenUionLocation(n); 

} 

pablic String getSeiviceOperatioQlaput( X 
return mServuxOperaticmlnput; 

} 

pablic String getServiceOperationlQputIbXML( ){ 

if (getServiceOperaLionInput( ) «> null) return null; 
char [ ] c » gptServtceOpBratioaIiq)ut( ).toCIiarAmy( ); 
StringBuffer sb - new StringBuffei( ); 
for (ist X « 0; X < ciengtft; X'M>){ 

s>K^tch(G(x]){ 

case '>': 

sb.append(-&g^"); 
bietJc; 
case *<': 

sb.appendC<"^ 
break; 
case 

sbjippend(*&''); 
break; 
case 

sb. append(-quot;"); 

break; 
case *V*: 

sb^peud("""); 

brcaJc; 
default: 

if (Character.isOcflned(c[x])) 
sb,append(c(x]); 

} 

} 
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remrn sb.toStruig( ); 

public void wtSeTvioeOpeiationInpiit(&riiig iDp){ 
thisjnScpriceOpeiationlDput - inp; 

public void 8eiviceOpentioiiInputFroinXML(String d){ 
setScrvtccOperation[iq)ut(n^ 

} 

public String getSeiviceOperBtionOu^ut( ){ 
return mServtoeOpenitioaChaput; 

public String getServiceOperatioaOu^>utToXML( ){ 
if (gctScrviccOpcrationOutput( ) ° null) return null; 
chai [ ] c » gctServiceOperadonOu^ut( ).toChaiAnay( ); 
StringBufTer sb - new StringBu£fer( ); 
for (int X = 0; X < clength; 

switch(c(x]){ 

case •>': 

»bJippead(*&gti"); 
bidJq 
case '<*: 

sbjippcnd(-<'>, 
break; 
case 

sb jippcndCAamp;*"); 
break; 
case 

sb^peadC&quct;"); 
bieait; 
case *Y*: 

sbjippeadC"**)! 
break; 
default: 

if (Character.isDeflned(c[xD) 
sb.append(c(x]); 

} 

} 

return sb.toString( ); 

} 

public void 8etServiceOpeiatiGnOtttput(String inp){ 
thisjnServiceOpcnitioiiOutput ~ iiq>; 

} 

public void 6eiviceOpemtionOulputFiDniXML(String o){ 
setScrviceOpei^k)nOo^pnt(a); 

} 

} 

package coni.veojcdk.devjschfiina.tcstblib; 
import com.veo.v^.docleLmeta.Document; 
public class ServiceSel extends Documait { 

public static final String DOCJTYPE " "scrvioe.set"; 
Service [ ] mServkx; 
public SeiviceSet( ){ 
8upcr(D0C_TYPE); 
tbisjnService « new Service[0]; 

} 

public SciviceSet(Stiing doc_Jype){ 
supcr(doc_typc); 
thisjnService = new Scrvice[0]; 

} 

static public ServiccSct imtSeiviceSet(Service [ ] iServioe){ 
ServiceSet obj «> new ServiceSet( ); 
obj.initializeAll(iServioeX 
return obj; 

public void imtializeAU(Service [ ] iService){ 
mSeivice » iSovice; 

public Service [ ] getSeivice( ){ 
return mScrvioe; 

> 

public Service getService(int index){ 
if (thLs.niScrvice == null) 

return null; 
if (index >- this.mServioe.length) 

return null; 

if (index < 0 && -index> this.mServLce.length) 
return null; 

if (index >= 0) return this.mScrvicc[index]; 
return this.mSefvice(thi&inService.leQgth + index]; 
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> 

public void 8etSeivice(int uKtex, Service Lnp){ 
if (this.mSeivice - ouU) { 
if (index < 0) { 
ttiis.mSeivice » new Service(l( 
this.mSeivice[0] - inp; 
}else{ 

this.mSeivice » new Sexvice[ittdex -i- 1^ 
tliis.mService[index] - inp; 

} 

} else if (index < 0) { 

Service [ ] newService - new Servicc{this.niService. length + 1^ 
java.]ang.Systcm.aiTayccpy((Object)mScrvice, 0, (Object)ttewService> 
0, ihisjnServuseiength); 

newSe]vice[ newService. length - 1] - tap; 
mScrvice = newService; 
} else if (index tliis.mService.Iength){ 

Service [ ] newService « new Service[index 1^ 
java.lang.System.arraycopy(((%!ject)mScrvice, 0, (Object)newSavice^ 
0, thisjnService.length); 

newService[index] - inp; 
m Service - newService; 
}clse{ 

thiB.mService[index] - inp; 

} ^ 

pnblic void setSeivioe(Seivice [ ] inp){ 
tUsjnService inp; 

} 



In addition to the JAVA beans set forth above, transfer- 30 
mation code is produced for translatiog from JAVA to XML 
and XML to JAVA as set forth below: 



Java to XML 
<!.DOCrYPE tiec SYSTEM "trccdtd"> 
<tree sottrcf; " "nulT" pass-4hrougb = "£alse'*> 
'd>e£Dre> 

name » *'attribate.der> 
<element source = "ATTRIBUTE" class = "NAME*" type » "5** positioa • ''-2"> 
<paise> 

<data class » ''java.lang.String'* positioa « **-T*f> 
<lpaxwa> 
•^elenient> 

<vardcf name - "podata-dcr> 

<element source - "PCDATA" class - "NAME" type - '•4"position - "-l'^ 
<paxsc> 

<data class - ''999^ type - -6" position - "-27> 
</parse> 
^element> 
<A'ardcf> 

<vardef name - "contcnLdef '> 
<element source • "PCDATA'S 
<paise> 

<datn class « "999" type - "6" position - "-2'7> 

<;;^3ar8e> 
</element> 
<Jvaidt(> 

<vardef name - "SeiviceSeLvnr^> 

^element source » **com.veojtdLdev.schenia.test.blib.SeiviceSef* class « "seivice^t^* type « "4" 
position « "-.2''> 
•^i8e> 

<callvar name - "Seivicc.var"> 
</parsc> 
'f/elcmcnt> 
</vardef> 

<vardef name • Trototyp6Servioe.var"> 

<eleiiient source « "com.veojcdk.dev.8chenia.test.blLb.PiototypeService" class - 
"piototypejervice** type - **4'* position - "-2**> 
<parse> 

<cailvar name - "pcdata.def' parms - "setSouroe ServioeMutteToXML setGeneiator 
service.name7> 
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<callvar oame ■> "pcdaca.def * paiins » ''setSouice Serviocl^nnsIbXML setGeneratot 
8avioe.tenn8"^ 

•ccaltvai name - "pcdala^ef* panns - **setSource SeivioeLocatioaTbXML setGeneiator 
scrvice.location7> 

<caUvar name « '*ServiceO|>ention.vai'7> 
</parse> 
^leineiit> 
</vardef> 

<vardef name - *'Seivice.var"> 

<elcment souicc ^'com.veojEdOcdev.schema.tesLblib.Seivice'* class >■ ^service" type « 
position = **0"> 
<paise> 

<callvar name ■> ''pcdata.def * panns » "setSource ServiceNameToXML setOeneiator 
service.name*V> 

<callvar name - **pcdata.deP* panns - "setSource ServioeLocationTbXML BetGenerator 
scrvicc.loaUion'y> 

<callvar name = "ServiceOperalion.var**> 

<caUvar name • ''pcdata.def ' panns - "setSource ServioeTennslbXML setGenerator 
8aviGe.tenns"/> 
<Jparst> 
</eleaient> 
</vardcf> 

<vardcf name = ''ScrviccOpcration.var"/^ 

<element souxoe « "com.veo^dk.dev.schema.tesLbUb.SeivioeOperation** class « 
"aervice.opention" type - poaitioa - **-7^> 

<piisc> 

•ccallvar name • "pcdata^er panns • "setSource ServioeOpeiatioaName'IbXML setGenemtor 
service.operatLon.aame7> 

<caUvar name - "pcdata.def* panns - "setSource SeiviceOpeiationLocationlbXML 
setGoiexator seivice.operation.location"/> 

<callvar name - "pcdata.def panna - "setSource ServiceOperationlnputToXML setGenemtor 
8ervtce.operation.uipur7> 

•ccallvar name > "pcdata.def * panns « "setSource SeivioeOperationCXitputTbXML 
setGenerator 8eivice.opeiation.outpa^V> 

</eleBieQt> 
•^/vardef> 

<paise> 

<callvai name - "SciviccSetvar"/> 
<callvar name - "PrototypeSeivice.var"/> 
<callvar name - "Servicc.\ar^;> 
<caHvai name - *'ServiceOperation.vai'7> 

</tree> 
XML to Java 

<!DOCrYPE tree SYSTEM -tree^td"> 
<tree source « "null" pass-through - "false"> 
<beforB> 

<vaidef name - "bvsiness.vaf *> 
«element souioc - "business' 

class - "com.veojGdk.dev^hema.tesLUib.Bu8ines8** 
type « "7' setter - "5ctBuaincss"> 
<bcforc> 

<onattribute name « "busmess.number"> 
<actions> 

<caUmeth name » "busuiessNumberPromXML"> 
^aniis> 

<getattr name - "businBss.numbei^/> 
</parms> 
</callmeth> 
<;/actions> 
</onattnbute> 
<before> 
<paise> 

•ccallvar name » "party Jizune.var^ panns « "sctPositton -!"/> 
<callvar name ■> "addiess^Lvai^/> 
^^pai8e> 
</elenient> 

<A'ardef> 

<vardef name - "party, name. var"> 
<clcmcnt source *> "party.name^' setter » "partyKamcFromXML" position • "-1" class 
•*java.lang.Stringf*> 
<5>aisc>> 

<data class - "javaJ8ng.Strin^* position - "0'7> 
</paist> 
</element> 
</vardc£> 

<vardef name = "dty.var'*> 
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<element source - "cily" setter - **cityftomXML" position = "-1" class » "javaJang^iring'S 
<ptiMse> 

<data class - ^^ava.lang.Strtiig'' posittoa - **(r/> 
<Jpaist> 
•(;/eleineat> 
</vBidef> 

<vaidef naoic « *HateraeLvar^> 

<element souioe » "intemet" setter » "intemetFroinXML*' position > "-l" class ■ 
"java.lang.String"> 
<paise> 

<data class » '^'ava.lang.String'* position » '*0'V> 
</paree> 
<yelciiicat> 
<J\faxdtt> 

<vaidef name - "country. vai"> 
<clcmcnt source • "country" setter ■ ''countryFroniXML" position - dass » 
"java.lang.String*'^ 
<paise> 

<data class « ''java.lang.String'* position * tr/> • 
/<paise> 
.^eleineat> 
<A'ardc£> 

<vaidef name » **staie.var"> 
^element souioe • ''state" setter • "stateFromXMU* position * "-1** class « "java.lang.String^ 
<pajsc> 

<data class = '^'ava.lang.String^ position ** "(r/> 

<yetea)ent> 
</varde& 

<vaidef name • **email.va]"'> 
<element source - "email'* setter "emailFrornXML** position - "-1" class - "jBva.lang.Strisg"> 
<parse> 

<data class » **java.Iang.String" position » **0"/> 
<Jpaise> 
</clemcat> 
</^nadtf> 

<vaidef name - *^ddres8.phy8ical.var"> 
<6lement souioe <• '*addiess4)hy5ical*' 

class > "com.veojcdlcdevjsdiema.testblib.AddressPhysical" 
type - "T* setter - "setAddresBPhysical^ 
<befbre> 
</before> 
<pax5e> 

<cailvar name = "strectvar*' panns = "sctPosition -1*7> 
<callvar name ■> "dty.var^ parms » "setPosition -l"/> 
<calIvBr name - "state. var^ panns - "setPosition -l"/> 
<caIlYar name • "postoode.vai^ panns • "setPosition ~l''f> 
<callvar name «• "oountry.vai^ parms «■ "setPosition -l"/> 
</pscttc> 
</clcmcat> 
</vanle& 

<vanlef name • "telepbone.vai^> 
^element source - "telephone"* setter - "lelephoncFiomXML" posUion - class - 
"ja^^lang.StringfV 
<paise> 

<data class - "java.lang.StTin^* position - "(r/> 

<;i>arsc> 
</elen)ent> 
</vnidef> 

<vanlef name » "person.vai^> 
^element source » •^rson" 

class - "com.veojcdlLdcv^h6ma.testblib.Per8on" 
type • "7" setter • "setPfci»on"> 
<before> 

<onattribute name - "SSN^> 
<actions> 

<caUn)eth name • "sSNFromXML"> 
^anns> 

<getattr oane • "SShr'/> 
</jpanns> 
•^^allmetli> 
</actions> 
</Qnattributo 
<;/bcfore> 

<callvar name «> "partyjome-var" parms - "setPosidon -17> 
<callvar name - *address.6et.vai^/> 
<;^>arsc> 
</element> 
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cvaidef name - "£iix.vBr^> 

<eleaient source » "&x" setter » "fiocFroinXML" posLtion « class -» •'java.laiig.Strmg"> 
<paise> 

«data class « "java.lasg.String" positioa « *'(r/> 
<paise> 
<eieinent> 

<vardef name « "street, var"> 
<clement source - "street" setter - "streetFromXML" position - class - "java.lang.String'V 
<parse> 

•^ta class - "java.lang.Slring" position = "0'V> 
^^»ise> 
</eleineat> 

<vaidef name « '"address.seLvar'S 
<element source » **addiess.set" 

class - ''com.veojEdk.dev.schema.testUibj\ddressSelT' 
type = "T setter «• **setAddressSct"> 
<bcforc> 
</\xfoTe> 

<p&TSt> 

<callv&r name - "address.physicaLvar'V 
•ecallvar name = "Iclcphone.var^ panns ■» "setPosition -!"/> 
<callvar name « "faxvar*' parms - "setPosition -17> 
Kcallvar name » "email.vax^' panns « "setPosition -l'V> 
<callvar name - "intemet.vai^ parms - "setPosition "-!**/> 
<fptme> 
<^emeat> 
^vanle£> 

<vafdef name - '^06tcode.vat^> 

<element source "po^code" setter - **postoodeFromXML" position > "-1** class » 
**java.laag.String^*> 
<paise> 

<data class - "java.lang.String** positioii - ''0'7> 
</ptme> 
</dement> 
^/varde& 

<vaidef name ■> ''markeLpaitkrqantvaf > 
<element source » "marketpaiticqHuif * 

class - "com.veojtdk-devjBchema.testWib.MaifcetPaitidpant'" 
type - "T* position - '*07> 
<before> 
^/before> 
<paise> 

<callvaT name - *buaincss.var7> 
<callvar name «> *^ison.vai'7> 



<;^jai5e> 




<^elcnient> 




<JWldtf> 




^before> 




<pax8e> 




<caUvar name 


m *business.vai^/> 


<callvar name 


- *'paity.name.var^/> 


<callvar name 


= "dty.vai^^ 


•ccallvar name 


= "intemctvar'7> 


<callvar name 


- "country. var*7> 


<caUvar name 


= "state. var"/> 


<callvai name 


- "emaiLvai'7> 


<callvar name 


= ''address.physicaLvai'7> 


<:callvar name 


= "tclcphonc.var**/> 


<calivar name 


- "person. va/7> 


<caUvar name 


--fii]Lvar^/> 


<Gallvai name 


- •*stiecLvai'7> 


«callvar name 


- "addiess^var7> 


<callvar name 


- "po8tcode.VBr"/> 


•ccallvar name 


- "marketpartidpantvaf 






<Ane> 
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-continued 



MalDBfiles: 



# 

# this malcefile was generated by bic versioa 0.0. 05/02/1998 

# 
# 

# get the package name &oin the package Bignment passed to SchemaOen 
PACKAGE_NAME = conVveo/xdk/dev/schema/tesVblib 
JAVA_SOURCES +- \ 

MarketPaitidpanLjavB \ 
Businessjava \ 
Person-java \ 
Party.java \ 

Adc^sPhysical.java \ 

AddiessSeLjava \ 
MAKEnUE_MASTER_DIR - xxx 
indiide $(MAKEF[LE.31ASriT3CJ>niVMakeme.iii^r 
all:: $CrAVA_CLASSES) 
# 

# this makefile was generated by bic versioa 0.0. 05/02/1998 
# 

# 
# 
# 



Makefiles: 



# this makefile was generated by bic veiston 0.0. OS/02/1998 
# 

# 
# 

10 * 

# get the package name from the package argument passed to SchemaGen 
PACKAGE_NAME - com/vco/xdk/dcv/schcmaAcst/blib 
JAVA^SOURCES \ 

# get the package name from the package argument passed to SchemaGen 
PACKAGE-NAME » com/veo/zdk/dev/scbcma/test/bUb 

15 JAVA^SOURCES 4« \ 
SeTviccSct.java \ 
PfOtotypeService.java \ 
Service.java \ 
Seivioe<^ratiott.java \ 
MAKEHLE-MASTER-DIR - xzx 
20 include $(MAKFILE_MASrEICJ^IR]/Makefile.niaster 
all:: $(JAVA_CIj\SSES) 



Finally, the XML document instances generated at run 
time according to the model above for one example foUows: 



<!DOCrYPE markct,partidpant SYSTEM '*maikeLpaiticipantdtd**> 
<ma£keLpaiticq}ant> 

•dbusiness business.numbei^'*1234567890^*> 

<party.name>IBM</^aityjiame> 

<address.set> 

<address.physical> 

<stieet>l IBM ^y<ytoeet> 

<ct^Palo Alto^city> 

<state>CA</state> 

<po5tcodc>94304<^xjstcode> 

<couatiy>USA<</coiuitiy> 

•</addies8.]^ysical> 

<telephone>123 456-7890<^Iepbone> 

<£ax>123 456 Q987</£uo 

<email>ibmec@ibm.oom^email> 

<^addrcss.set> 

<^iisiness> 

<^maiketpaiticipant> 

<!DOCTYPE service SYSTEM "service, dtd^ 

<service.se t> 

<servioe> 

^rvioe.niime>Oider Service Vseivicejiame> 

^rvioe.Iocatioa>www.ibm.com/order</'service^kxation> 

<servioe.operatioQ> 

^rvicc.opcratioQ.namoSubmit Order <servicc.opcratiorLaame> 
^rvLoe.operatLoa.location>www.ibm.coin/oider/submit</service.locatioa> 
<BervLoe.openition.input>ani:x-ibm:services:oidenoperationsqpo.dtd^/Be[vice.opeia^ 
<service.opemtion.outiit>uni:x> 

ibin:sexvices:oRler.opeiations.'poack.dtd<^rvice.opeiation.oulput> 

^service.operation> 

<Bervioe.operation> 

<scrvicc.qjeration.name>'nack Ordcr<^scivicc.operatioQjiamc> 

<service.opeiaUonJocatioik>www.ibnLoom/order/track</service.locatiott> 

<8ervioe.cperation.input>iini:x- 

ibm»eivices:order:qpeiations:trackirequestjdtd</savice.operation.input> 
<servLce.opeiatton.output>iun sc- 

ibm:services:o rde r:ope Tations:trackiresponse.dtd<^8ervice.ope[atLon.outpiit> 

<service.opeiation> 

^service> 

^service.set> 



Using the tools along with a BID composer application, 
which provides a drag, drop and forms editing user interface, 
65 a developer is able to create a business interface definition 
and to produce a well formed, valid business interface 
definition in the form of an XNiL document. Thus, the 
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example run time instance is a business interface definition 
for an ordering service for IBM to be used by Ingram Micro 
and others to order laptop computers from IBM. (There is no 
relationship between the applicant and IBM or Ingram 
Micro). Utilizing these processes, a user is able to build a ^ 
system that allows for programming of a business interface 
using the documents defined according to the present inven- 
tion. 

The role of CBL and the BID processor of the present 
invention in an XML/JAVA environment can be further 
tmdeistood by the following explanation of the processing of lO 
a Purchase Order. 

Company A defines its Purchase Order document type 
using a visual progranmiing environment that contains a 
library of CBL DTDs and modules, all defined using com- 
mon business language elements so that they contain data 
type and other interpretation information. Company A*s TO 
might just involve minor customizations to a more generic 
"transaction document" specification that comes with the 
CBL library, or it might be built firom the ground up from 
CBL modules for address, date and time, currency, etc. 

The documentation for the generic "transaction docu- 
ment*' specification (such as the traosact.dtd set out above) 
typifies the manner in which CBL specifications are built 
from modules and are interlinked with other CBL DTDs. 

A compiler takes the purchase order definition and gen- 
erates several different target forms. All of these target forms 25 
can be derived through "tree to tree" transformations of the 
original specification. The most important for this example 
are: 

(a) the XML DTD for the purchase order. 

Qj) a JAVA Bean that encapsulates the data structures for 30 
a purchase order (the JAVA classes, arguments, 
datatypes, methods, and exception structures are cre- 
ated that correspond to information in the Schema 
definition of the purchase order). 

(c) A "marshaling** program that converts purchase orders 35 
that conform to the Purchase Order DTD into a Pur- 
chase Order JAVA Bean or loads them into a database, 

or creates HTML (or an XSL style sheet) for displaying 
purchase orders in a browser. 

(d) An "^inmarshalin^ program that extracts the data ^ 
values £cDm Purchase Order JAVA Beans and converts 
them into an XML document that conforms to the 
Purchase Order DTD. 

Now, back to the scenario. A purchasing application 
generates a Purchase Order that conforms to the DTD ^5 
specified as the service interface for a supplier who accepts 
purchase orders. 

The parser uses the purchase order DTD to decompose the 
purchase order instance into a stream of information about 
the elements and attribute values it contains. These "prop- 50 
erty sets" are then transformed into corresponding JAVA 
event objects by wrapping them with JAVA code. This 
transformation in effect treats the pieces of marked-up XML 
document as instructions in a custom programming language 
whose grammar is defined by the DTD. These JAVA events 
can now be processed by the marshaling applications gen- 
erated by the compiler to "load'* JAVA Bean data structures. 

Turning the XML document into a set of events for JAVA 
applications to process^ is unlike the normal model of 
parsing in which the parser output is maintained as an 
internal data structure and processing does not begin until 
parsing completes. The event based processing, in response 
to the BID definitions, is the key to enabling the much richer 
functionality of the processor because it allows concurrent 
document application processing to begin as soon as the first 
event is emitted. 65 

JAVA programs that "listen for** events of various types 
are gpnerated from the Schema definition of those events. 



These listeners are pro-ams created to carry out the busi- 
ness logic associated with the XML definitions in the CBL; 
for example, associated with an "address" element may be 
code that validates the postal code by cheddng a database. 
These listeners "subscribe" to events by registering with the 
document router, which directs the relevant events to all the 
subscribers who are interested in them. 

This publish and subscribe architecture means that new 
listener programs can be added without knowledge by or 
impact on existing ones. Each listener has a queue into 
which the router directs its events, which enables multiple 
listeners can handle events in parallel at their own pace. 

For the example purchase order here, there might be 
listeners for: 

the purchase order, which would connect it to an order 

entry program, 
product descriptions, which might check inventory, 
address information, which could check Fed Ex or other 

service for delivery availability, 
buyer information, which could check order history (for 
creditworthiness, or to offer a promotion, or similar 
processing based on knowing who the customer is). 
Complex Listeners can be created as configurations of 
primitive ones (e.g., a purchase order listener may contain 
and invoke these listeners here, or they may be invoked on 
their own). 

FIG. 11 illustrates the market maker node in the network 
of FIG. 1. The market maker node includes the basic 
structures of the system of FIG. 3, including a network 
interface UOl, a document parser 1102, a document to host 
and host to document translator 1103, and a front end 1104, 
referred to as a router in this example. The market maker 
module 1105 in this example inchides a set of business 
interface definitions, or other identifiers sufficient to support 
the market maker function, for partidpants in the market, a 
CBL repository, and a compiler all serving the participants 
in the market The router 1104 includes a participant registry 
and document filters which respond to the events generated 
at the output of the translator and by the parser to route 
incoming documents according to the participant registry 
and according to the element and attribnite filters amongst 
the listeners to the XML event generators. Thus, certain 
participants in the market may register to receive documents 
that meet prespecified parameters. For example, input docu- 
ments according to a particular DTD, and including an 
attribute such as numbeis of products to be purchased 
greater than a threshold, or sudi as a maximum price of a 
document request to be piudiased, can be used to filter 
documents at the router 1104. Only such documents as 
match the information registered in the participant registry at 
the router 1104 are then passed on to the registered partici- 
pant 

The router 1104 may also serve local host senaces 1105 
and 1106, and as such act as a participant in the market as 
well as the market maker. Typically, documents that are 
received by the router 1104 are traversed to determine the 
destinations to which such documents should be routed, 
there again passed back through the translator 1103, if 
necessary, and out the network interface 1101 to the respec- 
tive destinations. 

The market maker is a server that binds together a set of 
internal and external business services to create a virtual 
enterprise or trading community. The server parses incoming 
documents and invokes the appropriate services by, for 
example, handing off a request for product data to a catalog 
server or forwarding a purchase order to an ERP system. The 
server also handles translation tasks, mapping the informa- 
tion from a company's XML documents onto document 
formats used by trading partners and into data formats 
required by its legacy systems. 
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lA^th respect to the service definitioo above, when a 
company submits a purchase order, the XML parser in the 
server uses the purchase order DTD to transform the pur- 
chase order instance into a stream of information events. 
These events are then routed to any application that is 
programmed to handle events of a given type; in some cases, 
the information is forwarded over the Internet to a different 
btisiness entirely. In the purchase order exanlple, several 
applications may act on informatk>n coming from the parser: 

An order entry program processes the purchase order as a 
complete message; 

An ERP system checks inventory for the products 
described in the purchase order; 

A customer database verifies or updates the customer's 
address; 

A shipping company uses the address information to 

schedule a delivery 
A bank uses the credit card information to authorize the 

transaction. 

Trading partners need only agree on the structure, content, 
and sequencing of the business documents they exchange, 
not on the details of APIs. How a document is processed and 
what actions result is strictly up to the business providing the 
service. This elevates integration from the system level to 
the business level. It enables a business to present a clean 
and stable interface to its business partners despite changes 
in its internal technology implementation, organization, or 
processes. 

FIGS. 12, 13 aiKl 14 illustrate processes executed at a 
market maker node in the system of FIG. 11. In FIG. 12, an 
input document is received at the network interface from an 
originating participant node (step 1200). The document is 
parsed (step 1201). The document is translated to the format 
of the host, for example XML to JAVA (step 1202). The host 
formatted events and objects are then passed to the router 
service (step 1203). The services registered to accept the 
document according to the document type and content of the 
document are identified (step 1204). The document or a 
poction of the document is passed to the identified services 
(step 1205). As service is performed in response to the 
document content (step 1206). The output data of the service 
is produced (step 1207). The ou^ut is converted to the 
document format, for example from a JAVA format to an 
XML format (step 1208). Finally, the output document is 
sent to a particq)ant node (step 1209). 

The registiation service is one such function which is 
managed by the router. Thus, a market participant document 
is accepted at the network interface as shown in FIG. 13 
(step 1300). The market participant document is stored in the 
business interface definition repository (step 1301) for the 
market maker node. In addition, the document is parsed 
(step 1302). The parsed document is translated into the 
format of the host (step 1303). Next, the document is passed 
to the router service (step 1304). The router service includes 
a listener which identifies the registration service as the 
destination of the document according to the document type 
and content (step 1305). The document or elements of the 
document are passed to the registration service (step 1306). 
In the registration service, the needed service specifications 
are retrieved according to the business interface definition 
(step 1307). If the service specifications arc gathered, at step 
13C^, the router service filters are set according to the 
business interface definition and the service specifications 
(step 1309). Registration acknowledgment data is produced 
(1310). The registration acknowledgment data is converted 
to a document format (step 1311). Finally, the acknowledg- 
ment dociunent is sent to the participant node indicating to 
the participant that is successfully registered with the market 
maker (step 1312). 



The process at step 1307 of gathering needed service 
specifications is illustrated for one example in FIG. 14. This 
process begins by locating a service business interface 
definition supported by the market participant (step 1400). 
The service definition is retricve4 for example by an E-mail 
transaction or web access to repository node (step 1401). 
The service specification is stored in the BID repository 
(step 1402). The service business interface definition docu- 
ment is parsed (step 1403). The parsed document is trans- 
lated into the format of the host (step 1404). Host objects are 

10 passed to the router service (step 1405). The registration 
service is identified according to the document type and 
content (step 1406). Finally, the information in the service 
business interface definition document is passed to the 
registration service (step 1407) for use according to the 

j5 process of FIG. 13. 

FIG. 15 illustrates the processor, components and 
sequence of processing of incoming data at market maker 
node according to the present invention. The market maker 
node includes a oommunicatioD agent 1500 at the network 
interface. The communication agent is coupled with an 

^ XML parser 1501 which supplies events to an XML pro- 
cessor 1502. The XML processor supplies events to a 
document router. The document router feeds a document 
service 1504 that provides an interface for supplying the 
received documents to the enterprise solution software 1505 

25 in the host system. The communication agent 1500 is an 
Internet interface which includes appropriate protocol stacks 
supporting such protocols as HTTP, SMTP, FTP, or other 
protocols. Thus, the incoming data could come in an XML 
syntax, an ASCII data syntax or other syntax as suits a 

30 particular communication channel. All the documents 
received in non-XML syntaxes are translated into XML and 
passed the XML parser. A translation table 1506 is used to 
support the translation firom non-XML form into XML form. 
The converted documents are supplied to the parser 1501. 

35 The XML parser parses the received XML document 
according to the document type definition which matches it. 
If an error is found, then the parser sends the document back 
to the communication agent 1500. A business interface 
definition compiler BIDC 1507 acts as a compiler for 
business interface definition data. The DTD file for the XML 

^ parser, JiWA beans corresponding to the DTD file, and 
translation rules for translating DTD files to JAVAbeans are 
created by compiling the BID data. An XML instance is 
translated to JAVA instance by referring to these tools. Thus 
the BID oon^iler 1507 stores the DTD documents 1508 and 

^5 produces JAVA documents which correspond 1509. The 
XML documents are passed to the processor 1502 which 
translates them into the JAVA format. In a preferred system, 
JAV\ documents which have the same status as the docu- 
ment type definitions received in the XML format are 

so produced. The JAV^ beans are passed to the document 
router 1503. The document router 1503 receives the JAVA 
beans and passes the received class to the appropriate 
document service using a registry program, for example 
using the event listener architecture described above. The 
document service 1504 which receives the document in the 
form of JAVA beans fix)m the router 1503 acts as the 
interface to the enterprise solution software. This includes a 
registry service 1510 by which listeners to XML events are 
coupled with the incoming data streams, and a service 
manager 1511 to manage the routing of the incoming 
documents to the appropriate services. The document ser- 
vice manager 1511 provides for administration of the reg- 
istry service and for maintaining document consistency and 
the like. 

The document service communicates with the back end 
65 system using any proprietary API, or using such more 
common forms as the CORBA/COM interface or other 
architectures. 
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FIG. 16 provides a heuristic ddagram of the market maker 
and market participant stnicturcs according to the present 
invention. Thus, the electronic commerce market according 
to the present invention can be logically organized as set 
forth in FIG. 16. At the top of the organization, a market 
maker node 1600 is established. The market maker node 
includes resources that establish a marketplace 1601. Such 
resources include a market registry service and the like. 
Businesses 1602 register in the marketplace 1601 by pub- 
lishing a business interface definition. The business interface 
definition defines the services 1603 for commercial trans- 
actions in which the businesses will participate. The trans- 
actions 1604 and services 1603 use documents 1605 to 
define the iiiputs and outputs, and outline the commercial 
relationship between participants in the transaction. The 
documents have content 1606 which carrks the particulars 
of each transaction. The manner in which the content is 
processed by the participants in the market, and by the 
market maker is completely independent of the document 
based electronic commerce network which is established 
according to the present invention. OveraU, a robust, 
scalable, intuitive structure is presented for enabling elec- 
tronic conuneice on communication networks is provided. 

Thus, the present invention in an exemplary syst^ 
provides a platform based on the XML processor and uses 
XML documents as the interface betM^n loosely coupled 
business systems. The documents are transferred between 
businesses and processed by participant nodes before enter- 
ing the company business system. Thus the platform enables 
electronic commerce applications between businesses where 
each business system operates using different internal com- 
merce platforms, processes and semantics, by specifying a 
common set of business documents and forms. 

According to the present invention, virtual enterprises are 
created by interconnecting business systems and service, are 
primarily defined in terms of the documents (XML-encoded) 
that businesses accept and generate: 

"if you send me a request for a catalog, I will send you a 
catalog: 

"if you send me a purchase order and I can accept it, I will 
send you an invoice". 

The foregoing description of a preferred embodiment of 
the invention has been presented for purposes of illustration 
and description. It is not intended to be exhaustive or to limit 
the invention to the precise forms disclosed. Obviously, 
many modifications and variations wiU be apparent to prac- 
titioners skilled in this art. It is intended that the scope of the 
invention be defined by the following claims and their 
equivalents. 

What is claimed is: 

1. A method for managing transactions among nodes in a 
network including a plurality of nodes which execute pro- 
cesses involved in the transactions, comprising: 

storing machine-readable ^>ecifications of a plurality of 
participant interfaces, the participant interfaces identi- 
fying transactions, the respective transactions being 
identified by definitions of input documents, and defi- 
nitions of output documents, the definitions of the input 
and output documents comprising respective descrip- 
tions of sets of storage units and bgical structures for 
the sets of storage units; 

receiving data comprising a document through a commu- 
nication network; 

parsing the dociunent according to the specifications to 
identify an input document and one or more transac- 
tions which accept the identified input document; 

providing at least a portion of the input document in a 
machine-readable format to transaction processes asso- 
ciated with the one or more identified transactions. 



2. The method of claim 1, including: 

providing a repository storing a library of logical 
stmctures, schematic maps for logic structures, and 
definitions of documents comprising logic structures 
5 used to build participant interface descriptions. 

3. The method of claim 2, including providing access to 
the repository through the communication network to other 
nodes in the network. 

4. The method of claim 1, wherein the machine-readable 
specification includes documents compliant with a definition 
of a participant interface document including logical struc- 
tures for storing an identifier of a particular transaction, and 
at least one of definitions and leferenoes to definitions of 
input and output documents for the particular transaction. 

5. The method of claim 1, wherein the machine-readable 
15 specifications include documents compliant with a definition 

of a participant interface document including logical struc- 
tures for storing an identifier of the participant interface, and 
for storing at least one of specifications and references to 
specifications of a set of one or more transactions supported 
by the participant interface. 

6. The method of claim 5, wherein the documents com- 
pliant with a definition of a participant interface document 
include a reference to a specification of a particular 
transaction, and the specification of the particular transac- 
tion includes a document including logical structures for 

^ storing at least one of definitions and references to defini- 
tions of input and output documents for the particular 
transaction. 

7. The method of claim 1, wherein the storage imits 
comprise parsed data. 

30 8. The method of claim 7, wherein the parsed data in at 
least one of the input and output documents comprises: . 
character data encoding text characters in the one of the 

input and output documents, and 
markup data identifying sets of storage units according to 
35 the logical structure of the one of the input and output 
documents. 

9. The method of claim 8, wherein at least one of the sets 
of storage units encodes a plurality of text characters pro- 
viding a natural language word. 

40 10. The method of claim 9, wherein the specification 
includes interpretation information for at least one of the sets 
of storage units identified by the logical structure of at least 
one of the input and output documents, encoding respective 
definitions for sets of parsed characters. 

^5 11. The method of claim 9, wherein the storage units 
comprise unparsed data. 

12. The method of claim 1, wherein the providing at least 
a portion of the input document in a machine-readable 
format to transaction processes associated with the one or 
more identified transactions includes executing a routing 
process according to a processing architecture, and includ- 
ing: 

compiling in response to the definitions of the input and 
output documents in the participant interfaces, data 
structures corresponding to the sets of storage units and 
logical structiures of the input and output documents 
compliant with the processing architecture of the trans- . 
action process, instructions executable by the system to 
translate the input document to the corresponding data 
stmctures. 

13. The method of claim 1, wherein the providing at least 
a portion of the input document in a machine-readable 
format to transaction processes associated with the one or 
more identified transactions includes executing a routing 
process according to a processing architecture, and includ- 
es ing translating at least of portion of the incoming document 

into a format readable according to the processing architec- 
ture. 
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14. The method of claim 13, wherein the translating more transactions which accept the identified input 
includes producing programming objects including van* document; and 

ables and methods according to the processing architecture logic to provide at least a portion of the input document 

of the routing process. in a machine-readable format to transaction pro- 

15. The method of claim 1, wherein providing at least a 5 cesses associated with the one or more identified 
portion of the input document in a machine-readable format transactions. 

to transaction processes associated with the one or more 26. The apparatus of claim 25, including a repository 

identified transactions, includes routing the portion of the stored in memory accessible by the data processor storing a 

input docimient to the identified transactiots. library of logical strucmres, schematic maps for logic 

16. The method of claim 15, wherein the routing includes structures, and definitions of documents comprising logic 
sending the input document on the communication network ^° structures used to buad partic^)ant interface descriptions, 
to a node executing one of the identified transactions. 27. The apparatus of daim 25, including logic to access 

17. The mediod of claim 1, wherein the definitions of the * repository stored in memory through the network interface 
input and output documents comprise document type defi- f ^^^S * ^^"^ ^. ^^^^^ schematic maps for 
nitions compUant with a standard Extensible Markup Lan- og?*^ structures, and definitions of documcnte comprising 
guage XML structures used to btiild participant mterface descnp- 

18. The method of claim 17, wherein the specifications of ^ * , . ^- . . . 
participant interfaces comprise definitions of documents ^f 'J^^ apparatus of claim 25, whercm the maclune- 
accoiding to document type definitions compKant 'With a ^^^^^}'^ specificaUon includes documents comphant witii a 
standard Extensible Markup Language XML. definition of a partiapant mterface document mchiding 

19. The method of claim 1, wherein the repository 20 ^^S^^^ structures for storing an identifier of a parUcular 
includes standardized document types for use in a plurality ^ansacuon, and at least one of definiuons and references to 
oftransactions, andwheieinthe definition ofoneof the input definitions of input and output documents for the particular 
and output documents includes a reference to a standardized ^ i , • . 
document type in the repository. ^9. The apparatus of claim 25, wherem the machine- 

20. The method of claim 19, wherein the repository „ readable specifications include documents compUant with a 
includes a standardized document type fijr identifying par- definition of a parUcipant mterface docuinent inchiding 
ticipant processes in the network. ^^^^^ structures for stormg an identifier of the parUapant 

21. nie method of daim 19, induding providing a reposi- interface, and for storing at least one of specifications and 
tory of interpietolfon information for logical structures. ^fferences to ^cifications of a set of one or more transac 
including interpretotion information identifying parameters si^ported by the participant mterface. 

of transactionsT ^ 30 30. The apparatus of claim 29, wherein the documents 

22. Hie method of claim 1. wherein the transaction compliant with a definition of a participant interface docu- 
processes have re^ctively one of a plurality of variant ^^P^^^e a reference to a specificaUon of a parUcular 
iransaction procesXg ardiitectures, and including translat- transacuon, and the speaficauon of the particular transac- 
ing at least of portion of the incoming document into a ^"^^^des a document including logical structures for 
format readable according to the variant Uansaction process- 35 stormg at least one of definitions and references to defim- 
ingarchitecmre of the respective transaction processes, and ^^^^ "^P*^^ ^ ^^^^^^ documents for the parUcular 
routing the translated portion to the respective transaction o . . ^- . . , 

process apparatus or claim 25, wherein the storage units 

23. The method of daim 22, wherein the translating ^^P^^ff P^^^ , . . . . ... 

includes producing programming objects including vari- 40 32. The apparatus ofclaim 31, wherem the parsed data m 

ables and methock according to the variant transaction ""P"^ ^^^P^^ documents comprises: 

processing architecture of the tc;q)ective traiBaction pro- character data encoding text characters in the one of the 

cesses. iapui and output documents, and 

24. The method of claim 23, wherein the variant trans- markup data identifying sets of storage units according to 
action processing architectures of the transaction processes the logical structure of the one of the input and output 
comprises a process compliant with an interface descriptioD documents. 

language. 33. The apparatus of claim 32, wherein at least one of the 

25. Apparatus for managing transactions among nodes in sets of storage units encodes a plurality of text characters 
a network including a plurality of nodes which execute providing a natural language word. 

processes involved in the transactions, comprising: 34. Hie apparatus of claim 33, wherein the specification 

a network interface; includes interpretation information for at least one of the sets 

memorystoringdalaandpiDgranisof mstnictions,includ- of storage units identified by the logical stnicture of at least 

ing inacliiiie-feadri)le specificatiois of a plurality of °^}^<' fP"' 't'^ ""'P"' '^^^^"^ 

p^dpam interfaces, the participant interfaces identi- deflnmons for sete of parsed Aarac^rs. 

^. \ 7! ^ y ^ ^. 35. The apparatus of claim 33, wherein the storage units 
fymg transactions, the respecUve transactions being 55 comprise unparsed data. 

idenufied bydefimuonsofmput documents and defi. 3^ apparaUis of claim 25, wherein tiie logic to 

muonsofoutput documents, the definiuons of the mput ^^^^^^ ^^^^^ ^ portion of tiie input document in a 

and output documents compnsmg respective descnp- machine-readable format to uansaction processes assodated 

tions of sets of storage units and togicalsUTicturesfi)r ^th die one or more identified transactions includes a 
the sets of storage units; gQ routing process according to a processing architecture, and 

a data processor coupled to the memory and the network including: 

interface which executes the programs of instructions; a compiler responsive to the definitions of the input and 
wherein the programs of instructions indude output documents in the participant interfaces, to corn- 
logic to receive data comprising a document through a pile data structures corresponding to the sets of storage 

netwoiic interface; 65 units and logical structures of the input and output 

logic to parse the document according to the specific documents compliant with the processing architecture 

cations to identify an input document and one or of the transaction process, and to compile instructions 



11/19/2003, EAST Version: 1.4.1 



6,125391 



89 



executable by the system to translate the input docu- 
ment to the corre^ooding data structures. 

37. The apparatus of claim 25, wherein the logic to 
provide at least a portion of the input docimaent in a 
machine-readable format to transaction processes associated 
with the one or more identified transactions includes a 
routing process according to a processing architecture, and 
includmg logic to translate at least of portion of the incom- 
ing document into a format readable aoooiding to the 
processing architecture. 

38. The apparatus of claim 37, wherein the logic to 
translate includes producing programming objects including 
variables and methods according to the processing architec- 
ture of the routing process. 

39. The apparatus of claim 25, wherein logic to provide at 
least a portion of the input document in a machine- readable 
format to transaction processes associated with the one or 
more identified transactions, includes a router to route the 
portion of the input document to the identified transactions. 

40. The apparatus of claim 39, wherein the router includes 
logic to send the input document on the network interface to 
a node executing one of the identified transactions. 

41. The apparatus of claim 25, wherein the definitions of 
the input and output documents comprise document type 
definitions compliant with a standard Extensible Maikup 
Language XML. 

42. The apparatus of claim 41, wherein the specifications 
of particqiant interfaces comprise definitions of documents 
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according to document type definitions compliant with a 
standard Extensible Markup Language XML. 

43. The apparatus of claim 26, wherein the repository 
inchides standardized document types for use in a plurality 
of transactions, and wherein the definition of one of the input 
and output documents includes a reference to a standardized 
document type in the repository. 

44. The apparatus of claim 26, wherein the repository 
includes a standardized document type for identifying par- 
ticipant processes in the network. 

45. The apparatus of claim 25, wherein the transaction 
processes have respectively one of a plurality of variant 
transaction processing architectures, and including logic to 
translate at least of portion of the incoming document into a 
format readable according to the variant transaction process- 
ing architecture of the respective transaction processes^ and 
to route the translated portion to the re^ective transaction 
processes. 

46. The apparatus of claim 45, wherein the logic to 
translate produces programming objects including variables 
and methods according to the variant transaction processing 
architecture of the respective transaction processes. 

47. The apparatus of claim 45, wherein the variant trans- 
action processing architectures of the transaction processes 
comprises a process compliant with an interface description 
language. 
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[57] ABSTRACT ' 

An iaterprise computing manager in which an application is 
composed of a client (firont end) program which communi- 
cates utilizing a network with a server (back end) program. 
The client and server programs are loosely coupled and 
exchange information using the network. The client program 
is composed of a User Interface (UI) and an object-oriented 
framework (Presentation Engine (PE) framework). The UI 
exchanges data messages with the framework. The frame- 
work is designed to handle two types of messages: (1) from 
the UI, and (2) from the server ^ack end) program via the 
network. The framework includes a component, the media- 
tor which manages messages coming into and going out of 
the framework. The system includes software for a client 
computer, a server computer and a network for connecting 
the client computer to the server computer which utilize an 
execution framework code segment configured to couple the 
server computer and the client computer via the network, by 
a phirality of client computer code segments resident on the 
server, each for transmission over the network to a client 
computer to initiate coupling; and a plurality of server 
computer code segments resident on the server which 
execute on the server in response to initiation of coupling via 
the network with a particular client utilizing the transmitted 
client computer code segment for commimicating via a 
particular communication protocol. Communication is ini- 
tiated utilizing the network to acquire characteristics of the 
client from the network. 

27 Claimsy 17 Drawing Sheets 
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Name 



Description 



Development 



Runtime 



Presentation Engine 
Class 



pe-template 



myPresentationEnqine 
(a developed and 
compiled Presentation 
Engine, given an 
example name here) 



Is the superclass for 

Presentation 

Engines. 

Is an instance of ttie 
PresentattonEngine 
class. 



Is an instance of the 
PresentationEngine 
class, created using 
pe-template, and 
filled in with 
application-specific 
code. 



Is derived from. 
Is not modified. 



Is modified. 
Developers copy 
this file, give it a 
name, and write 
method bodies for 
a few methods. 

Is developed from 
the pe-template. 



Is used by your 
instance of the 
Presentation 
Engine. 



FIG. 27 



A compiled 
Presentation 
Engine 
(here named 
myPresentation 
Enqine) that 
includes a GUI 
and an instance 
of the client 
Communication 
Library. 
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Function 

setSrvCommPropertiesO 



createMessageHandlersQ 



initializeApplicationO 



Description 

Sets server Communication 
Library properties such as 
server timeouts, and debug 
file and trace level. 



Registers the message 
handlers. Is the server 
analog to the. 
createMessageHandlersQ 
method in the Presentation 
Engine. 

Starts up the application- 
specific code. Is called 
after the server program 
accepts the connection 
from the dient and before 
the calls for reading and 
handling messages. 



Requirements 

Should not write anything to 
stdout because the ICE-T 
Access Layer expects the 
first thing written to stdout to 
be the port numt>er that the 
server uses to listen for the 
client connection. 

Called immediately after the 
setSrvCommProperties Q 
call. 



Initializes the data structures 
required for handling 
messages from the client. 
Must return. If the server 
program has its own notifier 
loop, such as a loop that 
receives notifications from 
the database, then that 
notifier must be called in a 
new thread. 



FIG. 28 



Property 

setServerTimeoutQ 
setDbgFite 
setAcceptTxmeout 
setTraceLevel 

setThreadModel 



Default Accepted Values 
3600 seconds (1 hour) 

stderr 

3600 seconds 
O(zero) 



SRVCOMM-THREAD- 

MODEL«SINGLE- 

HANDLER 



>0 

Specifying 0 or <0 means no timeout 
User-specified filename 

>0 

Specifying 0 or <0 means no hmeout 

0 means no trace messages are 

printed. 

2 means trace messages are printed. 

SRVCOb-'l- THREAD-MODEL- 
SINGLE HANDLER 

SRVCOI-THREAD-MODEL- 
MULTIPLE-HANDLERS 



FIG. 29 
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Table D-1 describes client and server-side exceptions 
Table D-1 ICE-T Exceptions 



Exception 

Exceptions thrown by the 
PeExceptlon 

MapNotFoundException 

DuplicateMapException 
CommException 

ConnectionException 



Description 

dient prol ram (Java code): 

A general exception that signifies an unidentitifed 
problem. The message may include more detail 
about where it was raised. Pe'^.xcep^ion is used 
very rarely. 

Raised when a module In the Presentation 

Engine Receives a message for which no 
map function has been registered. The 
message fexplains where and why the 
exception was raised. 

Raised when the client program attempts to 
register the same message in both the Ul and 
the Model. 

A aeneral communication exception. It is 
inoicated that there has been some 
communication problem and pnnts a message 
with more details. 

Indicates that there were some 
problems in connecting to the server. 



ICE-T protocol that 
Exceptions thrown by the Server Communication Library: 



PeProtocolExceptionlndicates that there was a 
problem with the is being sent between the 
client and server. 



ServerException 
SrvCommException 

SrvConnectionException 
SrvProtocolException 



The base class of the other exceptions. 
Never thrown. 

A general communication exception. Indicates 
that there has been some communication 
problem and prints a message with more details. 



Indicates that there is a problem with the 
connection to the client. It usually indicates that 
either the client has shut down unexpectedly or 
the connection has terminated, and the server is 
somehow continuing on. 

Indicates that there has been a problem with the 
message sent to, or received from, the client. 
Either the message type is unknown, or there has 
been a problem marshalling or unmarshaliing the 
data. It means that somehow the bytes that were 
sent on the socket were garbled. 



FIG. 30 
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OBJECT-ORIENTED SYSTEM, METHOD also typically includes a collection of utility programs that 

AND ARTICLE OF MA^fUE^\CTURE FOR A enable the computer system to perform basic operations, 

CLIENT-SERVER SESSION WEB ACCESS IN such as storing and retrieving information on a disc memory, 

AN INTERPRISE COMPUTING communicating with a network and performing file opera- 

FRAMEWORK SYSTEM. 5 tions including the creation, naming and renaming of files 

and, in some cases, pcrformiiig diagnostic operations in 

COPYRIGHT NOTIFICATION order to discover or recover from malfunctions. 

Portions of this patent application contain materials that P^" ^f the computing system is the "application 

are subject to copyright protection. The copyright owner has Program" which mtcracts with the operating system to 

no objection to the facsimUe reproduction by anyone of the P"'^"^^ ""C*" functionality, perform a specific 

patent document, or the patent disclosure, as it appears in the task and provide a direct intCTfaoe with the user. The 

Patent and Trademark Office. appLcabon program typically makes use of operatmg system 

functions by sending out series of task commands to the 

FIELD OF THE INVENTION operating system which then performs a requested task. For 

example, the application program may request that the 
This invention generally relates to improvements in com- operating system store particular information on the com- 
puter systems and, more particularly, to operating system p^ter disc memory or display information on the video 
software for managing Inteiprise computing in' a network display. 

user interface. j ^ schematic illustration of a typical prior art 

BACKGROUND OF THE INVENTION computer system utilizing both an application program and 

an operating system. The computer system is schematically 

One of the most important aspects of a modem computing represented by box 100, the application is represented by 

system is the interface between the human user and the box 102 and the operating system by box 106. The 

machine. The earliest and most popular type of interface was previously-described interaction between the application 

text based; a user communicated with the machine by typing ^ program 102 and the operating system 106 is illustrated 

text characters on a keyboard and the machine communi- schematically by arrow 104. This dual program system is 

cated with the user by displaying text characters on a display used on many types of computer systems ranging from main 

screen. More recently, graphic user interfaces have become frames to personal computers. 

popular where the machine communicates with a user by jhe method for handling screen diq)lays varies from 
displaying graphics, inchiding text and pictures, on a display ^ computer to computer and, in this regard, FIG. 1 represents 
screen and the user communicates with the machine both by ^ prfor art personal computer system. In order to provide 
typing in textual commands and by manipulating the dis- screen displays, application program 102 generally stores 
played pictures with a pointing device, such as a mouse. information to be displayed (the storing operation is shown 
Many modem computer systems operate with a graphic schematically by arrow 108) into a screen buffer 110. Under 
user interface called a window environment. In a typical control of various hardware and software in the system the 
window environment, the graphical display portrayed on the contents of the screen buffer 110 are read out of the buffer 
display screen is arranged to resemble the surface of an and provided, as indicated schematically by arrow 114, to a 
electronic ''desktop" and each application program running display adapter 112. The di^lay adapter 112 contains hard- 
on the conpiter is represented as one or more electronic ^ ware and software (sometimes in the form of firmware) 
"paper sheets" displayed in rectangular regions of the screen which converts the information in screen buffer HO to a 
called "windows". form which can be used to drive the display monitor 118 

Each window region generally displays information which is connected to display adapter 112 by cable 116. 
which is generated by the associated application program The prior art configuration shown in FIG. 1 generally 
and tiiere may be several window regions simultaneously 45 works well in a system where a single application program 
present on the desktop, each representing information gen- 102 is mnning at any given time. This simple system works 
era ted by a different application program. An application properly because the single application program 102 can 
program presents information to the user through each write information into any area of the entire screen buffer 
window by drawing or "painting" images, graphics or text area 110 without causing a display problem. However, if the 
within the window region. The user, in turn, communicates configuration shown in FIG. 1 is used in a computer system 
with the application by "pointing at" objects in the window where more than one application program 102 can be 
region with a cursor which is controlled by a pointing device operational at the same time (for example, a "multi-tasking" 
and manipulating the objects and also by typing information computer system) display problems can arise. More 
into the keyboard. The window regions may also be moved particularly, if each application program has access to the 
around on the display screen and changed in size and 55 entire screen buffer 110, in the absence of some direct 
appearance so that the user can arrange the desktop in a communication between applications, one application may 
conveiuent manner. overwrite a portion of the screen buffer which is being used 
Each of the window regions also typically includes a by another application, thereby causing the display gener- 
number of standard graphical objects such as sizing boxes, ated by one application to be overwritten by the display 
buttons and scroll bars. These features represent user inter- 50 generated by the other application, 
face devices that the user can point at with the cursor to Accordingly, mechanisms were developed to coordinate 
select and manipulate. When the devices are selected or theoperationof the application programs to ensure that each 
manipulated, the underlying application program is application program was confined to only a portion of the 
informed, via the window system, that the control has been screen buffer thereby separating the other displays. This 
manipulated by the user. 55 coordination became complicated in systems where win- 
In general, the window environment described above is dows were allowed to "overlap" on the screen display. When 
part of the computer operating system. The operating system the screen display is arranged so that windows appear to 
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** overlap", a window which appears on the screen in "front'* display monitors, keyboards, pointing devices, such as mice 

of another window covers and obscures part of the under- or trackballs, and other standard components, including 

lying window. Thus, except for the foremost window, only printers and disc drives. The next or "component driver 

part of the underlying windows may be drawn on the screen software" level consists of device-dependent software that 
and be 'Visible" at any given time. Further, because the 5 generates the commands and signals necessary to operate the 

windows can be moved or resized by the user, the portion of various hardware components. The resource control and 

each window whidi is visible changes as other windows arc communication layer interfaces with the component drivers 
moved or resized. Hius the portion of the screeri buffer ^^^^^^ software routines which allocate resources, 

which IS assigned to each apphcauon wmdow also changes communicate between applications and multiplex commu- 

as wmdows from other apphcations are moved or resized. ^^^^^^ ^ , underlying 

In order to effiaently manage the changes to the screen ^ ^ ^^^^ j^^^^^^ 

buffer necessary to accommodate rapid screen dbanges ^^.^ ^^^^ operationsf such as moving and resizing 
caused by movmg or resizmg wmdows, the pnor art com- . . ^- • ^« • j j j • 

puter arrangement shown in FIG, 1 was modified as shown wmdows, activating or macdvatmg windows and redrawmg 

in FIG. 2. In this new arrangement computer system 200 is ."^P^'^.^?^, .^^ .^"^ 
controlled by ooe or more application programs, of which provides high level facihtics that implement the various 
programs 202 and 216 are shown, which programs may be controls (buttons, sliders, boxes and other controls) that 
running simultaneously in the computer system. Each of the application programs use to develop a complete user inter- 
programs interfaces with the operating system 204 as illus- ^^ce. 

trated schematically by arrows 206 and 220. However, in Although the arrangement shown in FIG. 2 solves the 
order to display information on the display screen, applica- 20 display screen interference problem, it suffers from the 
tion programs 202 and 216 send display information to a drawback that the window manager 218 must process the 
central window manager program 218 located in the oper- screen display requests generated by all of the application 
ating system 204. The window manager program 218, in programs. Since the requests can only be processed seriaUy, 
turn, interfaces directly with the screen buffer 210 as illus- the requests are queued for presentation to the window 
trated schematically by arrow 208. The contents of screen ^5 manager before each request is processed to generate a 
buffer 210 are provided, as indicated by arrow 212, to a display on terminal 224. In a display where many windows 
display adapter 214 which is connected by a cable 222 to a arc present simultaneously on the screen, the window man- 
display monitor 224. ^g^r 218 can easily become a "botUeneck" for display 
In such a system, the window mana^r 218 is generally information and prevent rapid changes of the display by the 
responsible for maintaining all of the window displays that appUcation programs 202 and 216. Adelay in the redrawing 
the user views during operation of the application programs. ^he screen when windows are moved or repositioned by 
Since the window manager 218 is in communication with all ^he user often manifests itself by the appearance that the 
application programs, it can coordinate between appUcations windows are being constructed in a piecemeal fashion which 
to insure that window displays do not overlap. becomes annoying and detracts from the operation of the 
Consequently, it is generally the task of the window manager system. 

to keep track of the location and size of the window and the problem becomes even more accentuated in a client- 
window areas which must be drawn and redrawn as win- ^^^ver environment where many applications are all in 
dows are moved contention for very limited resources. The Internet has 
The window manager 218 receives display requests from P^nneated the workplace as a communication medium of 
each of the applications 202 and 216. However, since only ^ ^^"^ accessible from almc«t any pomt 
the window manager 218 interfaces with the screen buffer ^ « typical busmess enterprise a new buzzword has evolved 
210, it can aUocate respective areas of the screen buffer 210 ^^'^ enterprise computer mto an enterprise 
for each appUcation and insure that no appUcation errone- computer. Interpnse is a concatenaUon of mtemet and enter- 
ously overwrites the dii^lay generated by another applica- pnse. . . 
lion. There are a number of different window environments « . !□ today s cheat server enterprises, applications that ensi 
commerdaUy available which utOize the arrangement illus- "r^"' f enterprises are not rea^y budt to be 
trated in FIG. 2. ITiese include the XAVindow Operating '"''^^g"* ^ architected for distribtited system 
environment, the WINDOWS, graphical user interface environments. New systems ai* also required to be 
developed by the Microsoft Coiporation and the OS/2 ewluUonary. not revolut,on.ry.Red«agn of current system 
Presentation Manager, developed by the International Busi- ^ agmficant expense need to be avoided, 
ness Machines Corporation, and the Macintosh OS. devel- ^ system is required that allows a user to cieate manage- 
oped by Apple Computer Corporation. appliratio^ that can be readily deployed. mstaUed on 
Each of these window environmenls has its own internal f ^^.^^'^ »' P\»*'">^ configured to facdilate parUUor|- 
. ^ . , * ^ n i_ 1 mg them on clients versus servers and admmister the apph- 
software architecture, but the architectures can all be clas- ,^7. ^. , • c . j »* 1 u t 
, '. , J 1 • I * u - t 55 cations once they re runnmg. Systems don t always break 
sified by usmg a multi-layer model similar to the multi-layer , c ^ -t u »u 4- li 
J, ^ ^ tf * ^ 1 A because of failure, errors, or bug^, they sometimes break 
models used to describe computer network software. A . , . ,r . i- ' j , . , 
typical multi-layer model inchides (he following layers: the enterprise iteelf is ooinphcated »nd somebody 
iTitrf does somethmg unexpected somewhere which will bnng the 
User Interlace whole system down. When the system does come down, 
Wndow Manager ^ ^^^^ ^ system administrator must be able to readily identify 
Resource Cbntiol and Communication the problems, and deal with them in an effective manner so 
Component Driver Software that a business doesn't stop functioning when one of these 
Computer Hardware unforeseen events happens, 
where the term "window environment** refers to all of the The application should be designed based on domain 
above layers taken together 65 requirements, so it is independent of any platform 
The lowest or computer hardware level includes the basic undemeath, and fits more with how commercial developers 
computer and associated input and output devices including work. In the commercial world, the development process 
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isn't that important. The regular employees are not applica- 
tions developers or programmers. Companies usually hire 
such work out; they get consultants to do that kind of work. 
Depending on the company and what they want done, it 
usually hires a consulting firm, individual coiisultants, or 
smaller groups of considtants to come in, help it develop an 
application. Their goal is the cod application, which must be 
maintained. The contpany configures it, evolves it, and 
grows it. To allow for modification, the develqpmeot task 
must be modular to allow different groups of people working 
on different parts of an application, without requiring any 
one group to understand every detail of the whole applica- 
tion of the enterprise. 

The second criterion requires minimal extra knowledge, 
burden or sophistication on the part of the people developing 
the system. Most companies do not desire to have their 
business hinge on a single individual. Rather, they desire to 
have people who are primarily domaiii experts who can 
work with well-imderstood tools to produce a application 
matching company requirements quickly without making 
special demands on the company. 

SUMMARY OF THE INVENTION 

Hie foregoing problems are overcome in an illustrative 
embodiment of the invention in "wtns^ an application is 
composed of a client (&ont end) program which communi- 
cates utilizing a network with a server (back end) program. 
The client and server programs are loosely coupled and 
exchange information using the network. The client program 
is composed of a User Interface (UI) and an object-oriented 
framework (Presentation Engine (PE) framework). The UI 
exchanges data messages with the framework. The frame- 
work is designed to handle two types of messages: (1) from 
the UI, and (2) from the server (b&ck end) program via the 
network. The framework includes a component, the media- 
tor which manages messages coming into and going out of 
the framework. A distributed computer system is disclosed 
with software for a client computer, a server computer and 
a network for connecting the client computer to the server 
computer which utilize an execution framework code seg- 
ment configured to couple the server computer and the client 
computer via the network, by a plurality of client computer 
code segments resident on the server, eadi for transmission 
over the network to a client computer to initiate coupling; 
and a plurality of server computer code segments resident on 
the server which execute on the server in response to 
initiation of coupling via the networtc with a particular client 
utilizing the transmitted client computer code segment for 
communicating via a particular conmiunication protocol. 
Communication is initiated utilizing the network to acquire 
characteristics of the client from the network. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The above and further advantages of the invention may be 
better understood by referring to the following description in 
conjunction with the accompanying drawings, in which: 

FIG. 1 is a schematic block diagram of a prior art 
computer system showing the relationship of the application 
program, the operating system, the screen buffer and the 
display monitor; 

HG. 2 is a schematic block diagram of a modification of 
the prior art system shown in FIG. 1 which allows several 
application programs ruiming simultaneously to generate 
screen displays; 

FIG. 3 is a schematic block diagram of a typical hardware 
configuration of a computer in accordance with the subject 
invention; 
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FIG. 4 is a block diagram in accordance with a preferred 
embodiment in an Enterprise Network; 

FIG. 5 illustrates how a preferred embodiment leverages 
Java to facilitate the establishment and implementation of 
5 sever-centric policies; 

FIG. 6 illustrates the processing associated with applica- 
tion startup in accordance with a preferred embodiment; 

FIG. 7 illustrates the three fundamental components of an 
application in accordance with a preferred embodiment; 

FIG. 8 illustrates the migration of an existing client-server 
application to one supported by a preferred embodiment; 

FIG. 9 is a block diagram illustrating a Presentation 
Engine in accordance with a preferred embodiment; 
IS FIG. 10 is a block diagram of a prior art chent server 
architecture; 

FIG. 11 illustrates an application in accordance with an 
alternate embodiment; 

FIG. 12 illustrates a server establishing contact with a 
client in accordance with an alternate embodiment; 

FIG. 13 illustrates a loosely coupled client-server appli- 
cation in accordance with an alternate embodiment; 

FIG. 14 illustrates the system integration task necessary to 
25 develop an application in accordance with a preferred 
embodiment; 

FIG. 15 is a block diagram illustrating the modular design 
of a client application in accordance with a preferred 

embodiment; 

30 FIG. 16 is a block diagram of a framework in accordance 
with an alternate embodiment; 

FIG. 17 illustrates the basic building blocks in accordance 
with an alternate embodiment; 

FIG. 18 is a block diagram highlighting the steps utilized 
to extend the framework in accordance with a preferred 
embodiment; 

FIG. 19 is an illustration of a Presentation Engine Object 
in accordance with a preferred embodiment; 

FIG. 20 is an illustration of a Presentation Engine Event 
Handler used by Views to handle incoming messages and 
User Interface events in accordance with a preferred 
embodiment; 

FIG. 21 illustrates a PEInfo object data in accordance with 
45 a preferred embodiment; 

FIG. 22 illustrates incoming message flow to a model in 
accordance with a preferred embodiment; 

FIG. 23 illustrates incoming messages mapping a User 
Interface to a Model in accordance with a preferred embcdi- 
50 ment; 

E^G. 24 illustrates outgoing messages mapping a model to 
messages in accordance with a preferred embodiment; 

FIG. 25 illustrates outgoing messages mapping a model to 
a User Interface in accordance with a preferred embodiment; 

FIG. 26 illustrates an arrangement that facilitates the 
launch and utilization of an application URL in accordance 
with a preferred embodiment; 

FIG. 27 is a table that describes the forms of a Presenta- 
^ tion Engine, as an abstract Java class, a template for 
development, and an executable component in an applica- 
tion in accordance with a preferred embodiment; 

FIG. 28 describes the functions developers must fill in 
using the server program template in accordance with a 
55 preferred embodiment; 

FIG. 29 illustrates Server Properties in accordance with a 
preferred embodiment; and 
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FIG. 30 is a table of client and server side exceptions in Objects are defined by creating '"classes" which are not 

accordance with a preferred embodiment. objects themselves, but which act as templates that instruct 

nirrATT nn nccr^DiwrinM compiler how to construct the actual object A class may, 

Uli JAiu:u Lit«>CKJr J luw example, specify the number and type of data variables 

The invention is preferably practiced in the context of an ^ and the steps involved in the functions which manipulate the 
operating system resident on a computer such as a SUN, data. An object is actually created in the program by means 
IBM, PS/2, or Apple, Macintosh, computer. A representative of a special function called a constructor which uses the 
hardware environment is depicted in FIG. 3, which illus- corresponding class definition and additional information, 
trates a typical hardware configuration of a computer 300 in such as arguments provided during object creation, to con- 
accordance with the subject invention. The computer 300 is jq struct the object Likewise objects are destroyed by a special 
controlled by a central processing unit 302 (which may be a function called a destructor. Objects may be used by using 
conventional microprocessor) and a number of other units, their data and invoking their functions, 
all interconnected via a system bus 308, are provided to The principle benefits of object-oriented programming 
accomplish specific tasks. Although a particular computer techniques arise out of three basic principles; encapsulation, 
may only havesomeof theimitsiUustratedinFlG.3, ormay polymorphic and inheritance. More ^edfically, objects 
have additional components not shown, most computers will can be designed to hide, or encapsulate, all, or a portion of, 
include at least the units shown. the internal data structure and the internal functions. More 

Specifically, computer 300 shown in FIG. 3 includes a - particularly, during program design,* a program -developer * 

random access memory (RAM) 306 for temporary storage of can define objects in which all or some of the data variables 

information, a read only memory (ROM) 304 for permanent 20 &11 or some of the related functions are considered 

storage of the computer's configuration and basic operating ''private" or for use only by the object itself. Other data or 

commands and an input/output (I/O) adapter 310 for con- functions can be declared "public'* or available for use by 

necting peripheral devices such as a di^ unit 313 and printer other programs. Access to the private variables by other 

314 to the bus 308, via cables 315 and 312, respectively. A programs can be controlled by defining public functions for 

user interface adapter 316 is also provided for connecting 2s object which access the object's private data. The public 

input devices, such as a keyboard 320, and other known functions form a controlled and consistent interface between 

interface devices including mice, speakers and microphones the private data and the "outside" world. Any attempt to 

to the bus 308. Visual output is provided by a display adapter write program code which directly accesses the private 

318 which connects the bus 308 to a display device 322, variables causes the compiler to generate an error, which 

such as a video monitor. The computer has resident thereon 30 stops the compilation process and prevents the program 

and is controlled and coordinated by operating system from being run. 

software such as the SUN Solaris or JavaOS operating Polymorphism is a concept which allows objects and 

system. functions which have the same overall format, but which 

In a preferred embodiment, the invention is implemented work with different data, to function differently in order to 

in the C++ programming language using object-oriented 35 produce consistent results. For example, an addition func- 

programming techniques. C++ is a compiled language, that tion may be defined as variable A plus variable B (A+B) and 

is, programs are written in a human-readable scrq)t and this this same format can be used whether the A and B are 

script is then provided to another program called a compiler numbers, characters or dollars and cents. However, the 

which generates a machine-readable numeric code that can actual program code which performs the addition may differ 

be loaded into, and directly executed by, a computer. As 40 widely depending on the type of variables that comprise A 

described below, the C++ language has certain characteris- and B. Polymorphism allows three separate function defi- 

tics which aUow a software developer to easily use programs nitions to be written, one for each type of variable (numbers, 

written by others while still providing a great deal of control characters and dollars). After the functions have been 

over the reuse of programs to prevent their destruction or defined, a program can later refer to the addition function by 

improper use. The C++ language is weU-known and many 45 its cocmion format (A+B) and, during compilation, the C++ 

articles and texts are available which describe the language compiler will determine which of the three functions is 

in detail. In addition, C++ compilers are commercially actually being used by examining the variable types. The 

available from several vendors including Borland compiler will then substitute the proper function code. 

International, Inc. and Microsoft Corporation. Accordingly, Polymorphism allows similar functions which produce 

forreasonsofclarity,thedetailsof the C++ language and the 50 analogous results to be '^grouped" in the program source 

operation of the C++ compiler will not be discussed further code to produce a more logical and clear program flow, 

in detail herein. The third principle which underlies object-oriented pro- 

As will be imderstood by those skilled in the art. Object- gramming is inheritance, which allows program developers 

Oriented Programming (OOP) techniques involve the to easily reuse pre-existing programs and to avoid creating 

definition, creation, use and destruction of "objects". These S5 software from scratch. The principle of inheritance allows a 

objects are software entities comprising data elements and software developer to declare classes (and the objects which 

routines, or functions^ which manipulate the data elements. are later created from them) as related. Specifically, classes 

The data and related fimctions are treated by the software as may be designated as subclasses of other base classes. A 

an entity and can be created, used and deleted as if they were subclass "inherits" and has access to all of die public 

a single item. Together, the data and functions enable objects 60 functions of its base classes just as if these function appeared 

to model virtually any real-worid entity in terms of its in the subclass. Alternatively, a subclass can override some 

characteristics, which can be represented by the data or all of its inherited functions or may modify some or all of 

elements, and its behavior, which can be represented by its its inherited functions merely by defining a new fimction 

data manipulation fiinctions. In this way, objects can model with the same form (overriding or modification does not 

concrete things like people and computers, and they can also 65 alter the function in the base class, but merely modifies the 

model abstract concepts like numbers or geometrical use of the function in the subclass). The creation of a new 

designs. subclass which has some of the fimctionality (with selective 
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modification) of another class allows software developers to 
easily customize existing code to meet their particular needs. 

Although object-oriented programming offers significant 
improvements over other programming concepts, program 
development still requires significant outlays of time and ^ 
effort, especially if no pre-existing software programs are 
available for modification. Consequently, a prior art 
approach has been to provide a program ckveloper with a set 
of pre-defined, interconnected classes which create a set of 
objects and additional miscellaneous routines that are all 
directed to performing commonly-encountered tasks in a 
particular environmcQt. Such pre-defined classes and librar- 
ies arc typically called "frameworks" and essentially provide 
a pre-fabricated structure for a working application. 

For example, a frameworic for a user interface might 
provide a set of pre-defined graphic interface objects which 
create windows, scroll bars, menus, etc. . and. provide the 
support and "default" behavior for these graphic interface 
objects. Since fimicworks arc based on object-oriented 
techniques, the pre-defined classes can be used as base 
classes and the built-in default behavior can be inherited by 
developer-defined subclasses and either modified or over- 
ridden to allow developers to extend the framework and 
create customized solutions in a particular area of expertise. 
TTiis object-oriented approach provides a major advantage ^ 
over traditional programming since the programmer is not 
changing the original program, but rather extending the 
capabilities of the original program. In addition, developers 
arc not blindly working through layers of code because the 
framework provides architectural guidance and modeling ^ 
and, at the same time, frees the developers to supply specific 
actions unique to the problem domain. 

There are many kinds of frameworks available, depending 
on the level of the system involved and the kind of problon 3^ 
to be solved. The types of frameworks range from high-level 
application frameworks that assist in developing a user 
interface, to lower-level frameworics that provide basic 
system software services such as communications, printing, 
file systems support, graphics, etc. Commercial examples of ^ 
application frameworks include MacApp (Apple), Bedrock 
(Symantec), OWL (Borland), NeXT Step App Kit (NeXT), 
and Smalltalk-80 MVC (ParcPlace). 

While the fi^mewoik approach utilizes all the principles 
of encapsulation, polymorphism, and inheritance in the 45 
object layer, and is a substantial improvement over other 
programming techniques, there are difficulties which arise. 
Application frameworks generally consist of one or more 
object ''layers'* on top of a monolithic operating system and 
even with the flexibility of the object layer, it is still ofren 50 
necessary to directly interact with the underlying operating 
system by means of awkward procedural calls. 

In the same way that an application framework provides 
the developer with prefabricated frmctionality for an appli- 
cation program, a system framework, such as that included ss 
in a preferred embodiment, can provide a prefabricated 
functionality for system level services which developers can 
modify or override to create customized solutions, thereby 
avoiding the awkward procedural calls necessary with the 
prior art application frameworks programs. For example, 60 
consider a display framework which could provide the 
foundation for creating, deleting and manipulating windows 
to display information generated by an application program. 
An application software developer who needed these capa- 
bilities would ordinarily have to write specific routines to 6S 
provide them. To do this with a framework, the developer 
only needs to supply the characteristics and behavior of the 
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finished display, while the framework provides the actual 
routines which perform the tasks. 

A preferred embodiment takes the concept of frameworks 
and applies it throughout the entire system, including the 
application and the operating system. For the commercial or 
corporate developer, systems integrator, or OEM, this means 
all of the advantages that have been illustrated for a frame- 
work such as MacApp can be leveraged not only at the 
application level for such things as text and user interfaces, 
but also at the system level, for services such as printing, 
graphics, multi-media, file systems, I/O, testing, etc. 

A preferred embodiment is written using JA\^ C, and the 
C++ language and utilizes object-oriented programming 
methodology. Object-oriented programming (OOP) has 
become increasingly used to develop complex applications. 
As OOP moves toward the mainstream of software design 
and developinent, various software solutions require, adap- 
tation to make use of the benefits of OOP. A need exists for 
these OOP principles to be applied to a messaging interface 
of an electronic messaging system such that a set of OOP 
classes and objects for the messaging interface can be 
provided. 

OOP is a process of developing computer software using 
objects, including the steps of analyzing the problem, 
designing the system, and constructing the program. An 
object is a software package that contains both data and a 
collection of related structures and procedures. Since it 
contains both data and a collection of structures and 
procedures, it can be visualized as a self-sufficient compo- 
nent that does not require other additional structures, pro- 
cedures or data to perform its specific task. OOP, therefore, 
views a computer program as a collection of largely autono- 
mous components, called objects, each of which is respon- 
sible for a ^cific task. This concept of packaging data, 
strucnues, and procedures together in one component or 
module is called encapsulation. 

In general, OOP components are reusable software mod- 
ules which present an interface that conforms to an object 
model and which are accessed at run-time through a com- 
ponent integration architecture. A component integration 
architecture is a set of architecture mechanisms which allow 
software modules in different process spaces to utilize each 
others' capabilities or functions. This is generally done by 
assuming a common component object model on which to 
build the architecture. 

It is worthwhile to differentiate between an object and a 
class of objects at this point. An object is a single instance 
of the class of objects, which is often just called a class. A 
class of objects can be viewed as a blueprint, from which 
many objects can be formed. 

OOP allows the programmer to create an object that is a 
part of another object For example, the object representing 
a piston engine is said to have a oomposition-rclationshq> 
with the object representing a piston. In reality, a piston 
engine comprises a piston, valves and many other compo- 
nents; the fact that a piston is an element of a piston engine 
can be logically and semantically represented in OOP by two 
objects. 

OOP also allows creation of an object that "depends 
from" another object If there are two objects, one repre- 
senting a piston engine and the other representing a piston 
engine wherein the piston is made of ceramic, then the 
relationship between the two objects is not that of compo- 
sition. A ceramic piston engine does' not make up a piston 
engine. Rather it is merely one kind of piston engine that has 
one mote limitation than the piston engine; its piston is made 
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of ceramic. In this case, the object representing the ceramic 
piston engine is called a derived object, and it inherits all of 
the aspects of the object representing the piston engine and 
adds fiirther limitation or detail to it. The object representing 
the ceramic piston engine "depends Cnom" the object repre- 5 
senting the piston engine. The relation^ip between these 
objects is called inheritance. 

When the object or class representing the ceramic piston 
engine inherits all of the aspects of the objects representing 
the piston engine, it inherits the thermal characteristics of a 10 
standard piston defined in the piston engine class. However, 
the ceramic piston engine object overrides these ceramic 
specific thermal characteristics, which are typically different 
from those associated with a metal piston. It skips over the 
original and uses new functions related to ceramic pistons. 
Different kinds of piston engines have different 
characteristics, but may have the same underlying functions 
associated with it (e.g., how many pistons in the engine, 
ignition sequences, lubrication, etc.). To access each of these 
functions in any piston engine object, a programmer would 20 
call the same fiinctions with the same names, but each type 
of piston engine may have different/overriding implemen- 
tations of functions behind the same name. This ability to 
hide different implementations of a function behind the same 
name is called polymorphism and it greatly simplifies com- 
munication among objects. 

With the concepts of composition-relationship, 
encapsulation, inheritance and polymorphism, an object can 
represent just about anything in the real world. In fact, our 
logical perception of the reality is the only limit on deter- 
mining the kinds of things that can become objects in 
object-oriented software. Some typical categories are as 
follows: 

Objects can represent physical objects, such as automo- 
biles in a traffic-flow simulation, electrical components 
in a circuit-design program, countries in an economics 
model, or aircraft in an air-traffic-control system. 

Objects can represent elements of the computer-user 
environment such as windows^ menus or graphics ^ 
objects. 

An object can represent an inventory, such as a personnel 
file or a table of the latitudes and longitudes of cities. 

An object can represent user-defined data types such as 
time, angles, and complex numbers, or points on the 45 
plane. 

^th this enormous capability of an object to represent 
just about any logically separable matters, OOP allows the 
software developer to design and implement a computer 
program that is a model of some aspects of reality, whether 50 
that reality is a physical entity, a process, a system, or a 
composition of mauer. Since the object can represent 
anything, the software developer can create an object which 
can be used as a component in a larger software project in 
the future. S5 

If 90% of a new OOP software program consists of 
proven, existing components made from preexisting reus- 
able objects, then only the remaining 10% of the new 
software project has to be written and tested from scratch. 
Since 90% already came from an inventory of extensively 60 
tested reusable objects, the potential domain from which an 
error could originate is 10% of the program. As a result, 
OOP enables software developers to build objects out of 
other, previously built, objects. 

This process closely resembles complex machinery being 65 
built out of assemblies and sub -assemblies. OOP 
technology, therefore, makes software engineering more like 
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hardware engineering in that software is built from existing 
components, which are available to the developer as objects. 
All this adds up to an improved quality of the software as 
well as an increased speed of its development. 

Programming languages are beginning to fully support the 
OOP principles, such as encapsulation, inheritance, 
polymorphism, and composition-relationship. With the 
advent of the C-i-f language, many commercial software 
developers have embraced OOP. C-h- is an OOP language 
that offers a fast, machine-executable code. Furthermore, 
is suitable for both commercial-application and 
systems-programming projects. For now, C++ appears to be 
the most popular choice among many OOP programmers, 
but there is a host of other OOP languages, such as 
Smalltalk, common lisp object system (CLOS), and Eiffel. 
Additionally, OOP capabilities are being added to more 
traditional popular computer programming languages such 
as Pascal. 

The benefits of object classes can be summarized, as 
follows: 

Objects and their corresponding classes break down com- 
plex programming problems into many smaller, sim- 
pler problems. 
Encapsulation enforces data abstraction through the orga- 
nization of data into small, independent objects that can 
conmiunicatc with each other. Encapsulation protects 
the data in an object from accidental damage, but 
allows other objects to interact with that data by calling 
the object's member functions and structures. 
Subclassing and inheritance make it possible to extend 
and modify objects through deriving new kinds of 
objects firom the standard classes available in the sys- 
tem. Thus, new capabilities are created without having 
to start from scratch. 
Polymorphism and multiple inheritance make it possible 
for different programmers to mix and match character- 
istics of many different classes and create specialized 
objects that can still work with related objects in 
predictable ways. 
Class hierarchies and containment hierarchies provide a 
flexible mechanism for modeling real-world objects 
and the relationships among them. 
Libraries of reusable classes are useful in many situations, 

but they also have some limitations. For example: 
Complexity. In a complex system, the class hierarchies for 
related classes can become extremely confusing, with 
many dozens or even hundreds of classes. 
Flow of control. A program written with the aid of class 
libraries is still responsible for the flow of control (i.e., 
it must control the interactions among all the objects 
created &om a particular library). The programmer has 
to decide whidh functions to call at what times for 
which kinds of objects. 
Duplicahon of effort. Although class libraries allow pro- 
grammers to use and reuse many small pieces of code, 
each programmer puts those pieces together in a dif- 
ferent way. Two different programmers can use the 
same set of class libraries to write two programs that do 
exactly the same thing but whose internal structure 
(i.e., design) may be quite different, depending on 
hundreds of small decisions each programmer makes 
along the way. Inevitably, similar pieces of code end up 
doing similar things in slightly different ways and do 
not work as well together as they should. 
Class libraries are very flexible. As programs grow more 
implex, more programmers are forced to reinvent basic 
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solutions to basic problems over and over again. A relatively 
new extension of the class Ubrary concept is to have a 
framework of class libraries. This framework is more com- 
plex and consists of significant collections of collaborating 
classes that capture both the small scale patterns and major 
mechanisms that implement the common requirements and 
design in a specific application domain. They were first 
developed to free application programmers from the chores 
involved in displaying menus, windows, dialog boxes, and 
other standard user interface elements for personal comput- 
ers. 

Frameworks also represent a change in the way program- 
mers think about the interaction between the code they write 
and code written by others. In the early days of procedural 
programming, the programmer called libraries provided by 
the operating system to perform certain tasks, but basically 
the program executed down the page from start to finish, and 
the programmer was solely responsible for the flow of 
control. This was appropriate for printing out paychecks, 
calculating a mathematical table, or solving other problems 
with a program that executed in just one way. 

Hie development of graphical user interfaces began to 
turn this procedural programming arrangement inside out. 
These inteifaces allow the tiser, rather than program logic, to 
drive the program and decide when certain actions should be 
performed. Today, most personal computer software accom- 
plishes this by means of an event loop vAiidk monitors the 
mouse, keyboard, and other sources of external events and 
calls the appropriate parts of the programmer's code accord- 
ing to actions that the user performs. Hie programmer no 
bnger determines the order in which events occur. Instead, 
a program is divided into separate pieces that are called at 
unpredictable times and in an unpredictable order. By relin- 
quishing control in this way to users, the developer creates 
a program that is much easier to use. Nevertheless, indi- 
vidual pieces of the program written by the developer still 
call hljraries provided by the operating system to accomplish 
certain tasks, and the programmer must still determine the 
flow of control within each piece after it's called by the 
event loop. Application code still ^sits on top of the system. 

Even event loop programs require prograimners to write 
a lot of code that should not need to be written separately for 
every application. The concept of an application framework 
carries the event loop concept frirther. Instead of dealing 
with all the nuts and bolts of constructing basic menus, 
windows, and dialog boxes and then making these things all 
work together, programmers using application frameworks 
start with working application code and basic user interface 
elements in place. Subsequently, they build from there by 
replacing some of the generic capabilities of the framework 
with the specific capabilities of the intended aiq}lication. 

^jplicaticm frameworks reduce the total amount of code 
that a programmer has to write from scratch. However, 
because the framewock is really a generic application that 
displays windows, supports copy and paste, and so on, the 
programmer can also relinquish control to a greater degree 
than event loop programs permit. The framework code takes 
care of almost all event handling aod flow of control, and the 
programmer's code is called only when the framework 
needs it (e.g., to create or manipulate a proprietary data 
structure). 

A programmer writing a framework program not only 
relinquishes control to the user (as is also true for event loop 
programs), but also relinquishes the detailed flow of control 
within the program to the framework. This approach allows 
the creation of more complex systems that work together in 
interesting ways, as opposed to isolated programs, having 
custom code, being created over and over again for similar 
problems. 
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Thus, as is explained above, a framework basically is a 
collection of cooperating classes that make up a reusable 
design solution for a given problem domain. It typically 
inchides objects that provide default behavior (e.g., for 
5 menus and windows), and programmers use it by inheriting 
some of that default behavior and overriding other behavior 
so that the framework calls application code at the appro- 
priate times. 

There are three main differences between frameworks and 

jQ class libraries: 

Behavior versus protocol Qass libraries are essentially 
collections of behaviors that you can call when you 
want those individual behaviors in your program. A 
framework, on the other hand, provides not only behav- 

15 ior but also the protocol or set of rules that govern the 
ways in which behaviors can be combined, including 
rules for what a programmer is supposed to provide 
versus what the framework provides. * - 
Call versus override. With a class library, the code the 

20 programmer instantiates objects and calls their member 
functions. It's possible to instantiate and call objects in 
the same way with a framework (i.e., to treat the 
framework as a class library), but to take full advantage 
of a framework's reusable design, a programmer typi- 

25 caUy writes code that overrides and is called by the 
framework. The framework manages the flow of con- 
trol among its objects. Writing a program involves 
dividing responsibilities among the various pieces of 
software that are called by the framework rather than 

30 specifying how the different pieces should work 
together. 

Implementation versus design. With class libraries, pro- 
grammers reuse only implementations, whereas with 
frameworks, they reuse design. A framework embodies 

35 the way a family of related programs or pieces of 
software work. It represents a generic design solution 
that can be adapted to a variety of specific problems in 
a given domain. For example, a single framework can 
embody the way a user interface works, even though 

40 two different user interfaces created with the same 
framework might solve quite different interface prob- 
lems. 

Thus, through the development of frameworks for solu- 
tions to various problems and programming tasks, signifi- 

45 cant reductions in the design and development effort for 
software can be achieved. A preferred embodiment of the 
invention utilizes HyperText Markup Language (HTML) to 
implement documents on the Intemet together with a 
general-purpose secure communication protocol for a trans- 

50 port medium between the client and the merchant. HTTP or 
other protocols could be readily substituted for HTML 
without undue experimentation. 

Information on these products is available in T. Berne rs- 
Lee, D. Connoly, "RFC 1866: Hypertext Markup 

55 Language— 2.0" (November 1995); and R. Fielding, H, 
Frystyk, T. Bemers-Lee, J. Gettys and J. C. Mogul, "Hyper- 
text Transfer Protocol— HTTP/1.1: HTTP Working Group 
Internet Draft" (May 2, 1996). HTML is a simple data 
format used to create hypertext documents that are portable 

60 from one platform to another. HTML documents are Stan- 
dard Generalized Markup Language (SMGL) documents 
with generic semantics that are appropriate for representing 
information from a wide range of domains. HTML has been 
in use by the World-Wide Web global information initiative 

65 since 1990. HTML is an application of ISO Standard 
8879:1986 Infonnation Processing Text and Ofl&ce Systems; 
Standard Generalized Marinip Language (SGML). 
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To date, Web development tools have been limited in their 
ability to create dynamic Web applications which span from 
client to server and interoperate with existing computing 
resotirces. Until recently, HTML has been the dominant 
technology used in development of Web-based solutions. 
However, KTML has proven to be inadequate in the fol- 
lowing areas: 

Poor performance; 

Restricted user interface capabilities; 

Can only produce static Web pages; 

Lack of interoperability with existing applications and 
data; and 

Inability to scale. 

Sun Microsystem's Java language solves many of the 
client-side problems by: 
Improving performance on the client side; 
Enabling the creation of dyaainic, real-time Web appli- 
cations; and 

Providing the ability to create a wide variety of user 
interface coooponents. 

Java is compiled into bytecodes in an intermediate form 
instead of machine code (like C, C-H-, Fortran, etc). The 
bytecodes execute on any machine with a bytecode inter- 
preter. TTius, Java applets can run on a variety of client 
machines, and the bytecodes are compact and designed to 
transmit efficiendy over a network which enhances a pre- 
ferred embodiment with universal clients and server-centric 
policies. 

>Wth Java, developers can create robust User Interface 
(UI) components. Custom **widgets" (e.g. real-time stock 
tickers, animated icons, etc.) can be created, and chent-side 
performance is improved. Unlike HTML, Java supports the 
notion of client-side validation, offloading appropriate pro- 
cessing onto the client for improved performance. Using the 
above-mentioned custom UI components, dynamic real- 
time Web pages can also be created. 

Sun*s Java language has emerged as an industry- 
recognized language for ^programming the Internet." Sun 
defines Java as: '"a simple, object-oriented, distributed, 
interpreted, robust, secure, architecture-neutral, portable, 
higb-performance, multithreaded, dynamic, buzzword- 
compliant, general-purpose programming language. Java 
supports programming for the Internet in the form of 
platform-independent Java applets/' Java applets are small, 
specialized applications that comply with Sun's Java Appli- 
cation Programming Interface (APQ allowing developers to 
add "interactive content" to Web documents (e.g. simple 
animations^ page adornments, basic games* etc.). inlets 
execute within a Java-compatible browser (e.g. Netscape 
Navigator) by copying code from the server to client From 
a language standpoint, Java's core feature set is based oo 
C-f-t*. Sun's Java literature states that Java is basically **C++, 
with extensions from Objective C for more dynamic method 
resolution". 

Another technology that provides similar function to 
JAVA is provided by Microsoft and ActiveX Technologies, 
to give developers and Web designers wherewithal to build 
dynamic content for the Internet and personal computers. 
ActiveX inchides tools for developing animation, 3-D vir- 
tual reality, video and other multimedia content These tools 
use Internet standards, work on multiple platforms, and are 
being supported by over 100 companies. The group's build- 
ing blocks are called ActiveX Controls, small, fast compo- 
nents that enable developers to embed parts of software in 
hypertext markup language (HTML) pages. ActiveX Con- 
trols work with a variety of programming languages includ- 
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ing Microsoft Visual C+'f , Borland Delphi, Microsoft \%ual 
Basic programming system and, in the future, Microsoft's 
development tool for Java, code named "Jakarta." ActiveX 
Technologies also includes ActiveX Server Framework, 

s allowing developers to create server applications. One of 
ordinary skill in the art readily recognizes that ActiveX 
could be substituted for JAVA without undue experimenta- 
tion to practice the invention. 
A preferred embodiment provides a system for building 

10 manageable applications. The applications can be readily 
deployed, on to a variety of platforms, and configured so that 
it's easy to partition them on to clients versus servers and 
administer the applications. A preferred embodiment is 
enabled as a client-server application that's distributed 

15 nodes in a multi-node platform. A single application is 
divided up into pieces and distributed across nodes in the 
network. Dims, an application is defined as a distributed 
systein. ' ' " " 

Enterprise computing systems are often a heterogeneous 

20 collection of nodes interconnected by a network. In a typical 
enviroiunent, a server node in the network holds data and 
programs that interact with the database, and a client node 
contains a program or programs for accessing the informa- 
tion on the server The complexity of these environments 

25 makes it difficult to create, configure, deploy and administer 
software applications. However, the advent of Web tech- 
nologies (browsers, the Java language and HTTP) has 
enabled enterprises to create and use internal Webs to assist 
in solving some of these problems. Java enables the Web as 

30 a client-server application platform and distribution channel 
to interact with a preferred embodiment in addressing many 
of the aforementioned challenges. 

A preferred embodiment includes a toolkit for creating 
client programs that can be downloaded from the Web; 

35 interfaces for enabling a server program to function with a 
client as a single application; tools for connecting both client 
programs and server programs with a framework for execut- 
ing the tools; and tools for installing, deploying and admin- 
istering applications. 

40 An application created in accordance with a preferred 
embodiment consists of a set of components that cooperate 
with each other. A server component can be implemented in 
any source language that can call a C program. A client 
component is implemented in the Java programming lan- 

45 guage. The client component consists of a Graphical User 
Interface (GUI) and a Presentation Engine (PE). To com- 
plete the application system, a preferred embodiment pro- 
vides a communication layer that enables the exchange of 
messages between the client and the server components, an 

so Exception layer for reporting errors, and an Access layer for 
managing application deployment. The task of an applica- 
tion developer utilizing a preferred embodiment is to 
assemble the components into an application system. 
A preferred embodiment provKies Java client access to 

55 server applications and can be utilized to create new appli- 
cations or extend existing applications. Among existing 
applications, those that are partitioned so that server pro- 
grams and databases are on the server, and user interfaces 
are on the client are especially suited for migration to the 

60 preferred embodiment. Other apphcations especially suited 
to a preferred embodiment require access to departmental or 
corporate data without changes to databases or the programs 
that access them. For enterprises already using the web 
technologies in an Internet, Intranet or other network 

65 environment, applications in accordance with a preferred 
embodiment provide quick access to existing data from 
anywhere in the organization or the world, implications in 
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accordance with a preferred embodiment can execute on any distributed platform on which the application is deployed, 

processor with tbe Java interpreter/runtime (Java JDK) or Thus, the application components and set of message events 

JavaOS installed. Application client programs are developed remain constant while the distributed platform can be scaled 

in Java using a null application template that contains the and modified. 

necessary Java classes and methods for integration with a 5^^ Since applications 440 are systems containing well 

Graphical User Interface (GUI). The template includes Java defined components as is shown in FIGS. 4 and 5, it is 

classes which will allow the client program to communicate possible to install sets of front ends 530 and back ends 540 

with the server program. Scripts and tools for installing and phis the definitions of how to associate them into applica- 

deploying applications, include a generalized startup a|>plet tions 440. The server node 520, therefore, holds all the 

for application launch from a Web browser or applet viewer. lO resources while the client node SCtfj^canogj y request acce ss. 

The primary development task in accordance with a t o the je sougros. The' serverDoiar^O isextended to allow 

preferred embodiment is to create an application front end it t o coptrol access to its resources b y enforcing well defined 

referred to as a Presentation Engine, hereinafter (PE), from policies. _ " ' * 

a provided template. The PE template includes methods ~^FI'G. 5 illustrates bow a preferred embodiment leverages 

(logic in an object) to send messages and their data through 15 Java to facilitate the establishment and implementation of 

a client communication library. Developers modify the tem- server-centric policies. The client 500 and server node 500 

plate to specify the messages and data required for their communicate utilizing the web technologies in an Internet, 

' applicatioii. The communication library handles the passing Intranet or other network environmeht/THe client node 500 

of messages and data across the network. The PE toolkit contacts the server node 520 via HTTP with a request to 

supports these tasks. The toolkit is a full set of Java 20 execute an application. After authenticating the client node 

components which can be modified and extended for a 500, the server node 520 selects front end 502 and back end 

particular application's requirements. The server program . 510 components based on the application definition list 

must also be enabled to communicate with the client by maintained at the server node 520. The server node 520 

specifying which handler fiinctions are called in response to starts its selected back end process 510 and sends the 

inbound messages and inserting ''send'" calls to a server- 25 selected front end program 502 to the client node 500 via the 

local communication library when data are sent to a client. Web technologies in an Internet, Intranet or other network 

The two PE development tasks are to: (1) connect a Java UI environment. Tbe client node 500 executes the selected front 

to the PE framework, and (2) define/describe the messages end 502 locally at the client node 500. The front end (client) 

to be exchanged between the PE and the server. programs 502 open a TCP/IP connection back to the server 

All of the components in accordance with a preferred 30 node 520 to initiate message passing in order to run the 

embodiment reside on the server so that the server controls applications. The selected front end program 502 is imple- 

all access to its resources. The server thus controls deploy- mented entirely in Java which facilitates instances of client/ 

ment and administration of its set of applications. The client s server applications which can run concurrently on a set of 

use the we b to jgcess the server's resources. A template is multi-platform clients nodes. The server node 520 is able to 

also provided fcr creatmg an applet that enables users at 35 send a selected front end program 502 to any client node 500 

client nodes to start applications from a browser which will which has the Java runtime installed on the computer. Server 

be discussed in added detail below, policies will not involve the clients. The policies will focus 

FIG. 4 is a block diagram in accordance with a preferred on the server's control of its local resources, 

embodiment in an Enterprise Network 450. The front end FIG. 5 also illustrates the loose coupling between the 

(client) 410 and back end (server) 400 create and receive 40 selected fronX end 502 and the selected back end 510 

data messages communicated via messages at their local application components. Each program includes a local 

communication libraries 420. Messages are events whidi are communication library 515. The front end library is imple- 

encoded in a protocol, *'ictp'' layered on top of Transmission mented in Java, the back end hbrary is implemented in C-i"i> 

Control Protocol/Internet Protocol (TCP/IP) The execution with a C API. The programs each utilize their local com- 

framework 430 layer could be implemented on any network 45 munication library API to send and receive messages. Thus, 

protocol as asynchronous, event-driven message passing on the programs do not communicate directly with each other, 

top of a communication protocol, such as TCP/IP, avoiding PRF^FNTATinN FNnnMF 

the dependencies of any particular server protocol. An PRbbblMlAllON LNOINh 

application has a specific set of message events, and each o^l^^^ are two phases for each application execution. In*" 

component (firont 410 and back 400 ends) includes local 50 the first phase, application startup, the cl i ent node requ ests 

handlers for the set of message events. Thus* any two ac c^ to the sejg g r node's r^ yuroe s annie server agsTSir 

components can be plugged into the execution framework tbiT rcquest. liie nodes are associated via the Internetor 



430 to form an application 440 if they include local handlers ot her communication nslapik. and thus do not have a_ 
for messages in the set of message events defined for the permanent reiationshq> w&Eio the enterprise. In the second 
application 440. The components each include a local 55 phase, application execution, th e client has received a front 
instanceof a communication library 420. A component only end Java program called a Presentation Engine (PE)IB . 
interacts with the Application Programming Interface (API) facI Etate presentafign servi ces. The>.fror ^"^ flnf1,fr^fj^f pd 
of its local oommunicatioD library 420 in order to send or aie pommunicating via the execution~frgDework oveTTCP / 
receive message events. IE- 
Application components in accordance with a preferred 60 FIG. 6 illustrates the processing associated with appUca- 
embodiment are "loosely coupled** because there is no direct tion startup in accordance with a preferred embodiment, 
dependence (or commimication) between the components. When an application is started, the client node 600 executes 
The execution framework 430 provides a consistent con- a startup applet 620 which first collects information about 
nection for all message transfer for the various applications. the client 600 user and contacts the server node 610 via 
The execution framework 430 supplies additional services, 65 HTTP 602. The server node 610 has been extended to 
such as error reporting, for the connection. An application include a web server 630 for processing requests via HTTP 
440 is insulated from the physical properties of the specific 602 over the Web technologies in an Internet, Intranet or 
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Other network envirooment. The access layer 640 is calledM than a third generation language programming task. FIG. 7 
via a cgi-bin interface from the web server 630. Th e access f illustrates the three fundamental components of an applica- 
layer 640 provid es a framework so that the information I tion in accordance with a preferred embodiment. The front 

end or presentation engine 700 on the client side 700, the 
back end 730 on the server node 710, and the node ICE-T 
execution framework 724 which facilitates the connection 
between the front end 700 and the back end 710. The 
application development process ooosisis of a plurality of 
steps. The first step defines the responsibilities of the front 
to end 700 and back end 710 components. A preferred embodi- 
ment is designed to facilitate migration of existing client/ 
server applications to function utilizing the Web technolo- 
gies in an Internet, Intranet or other network environment for 
communication services. This migration does not require 
redesigning existing application logic. The process entails 
the implementation of a new P£ front end implemented in 
the Java language which exchanges messages 735 with the 
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services, bbould authentication be successful, the access 
layer 640 uses the application name, which is also supplied 
by the startup applet 620, and invokes the app manager 650. 
Ilie app manager 650 handles the application definitions 
installed on the server node 610. The app manager 650 
selects the application back end 660 and initiates the pro- 
cessing. A listener socket is opened on the server node, and 
the port number is returned to the app manager 650. The app 
manager 650 also selects the application Front End (PE) 
670, stored on the server node 610 as a set of Java bytecodes, 
and creates a selected PE 680 instance which includes the 
listener socket port number, implication startup ends when 

the PE 680'instaiice is downloaded to the client node 600 fr)r' ^ remaining server back end code 730. RG. 8 illiistrates the 

execution. migration of an existing client-server application to one 

20 supported by a preferred embodiment. 

The new Java PE front end 820 is added to the existing 

Now referring to FIG. 7, when application execution is application code and will contain the Presentation Layer (UI 

initiated, the client node 705 begins to interpret the PE 700 tier) 800 and some amount of non-database aware logic 

it has received from the server node 710. The PE 700 is a responsible for manipulating variables as shown by Presen- 
framework (which includes an User Interface (UI) which ^ totion Layer (UI tier) 810. All logic which is aware of the 

can include a graphical UI (GUI)) and an instance of ICE-T database and its data remains in the back end component, 

a communication library 720 implemented in Java, Once it The PE 820 is not limited to logic from the existing 

starts up, the PE 700 opens a socket connection to the server application. It is a program implemented in Java, and thus 

node 710 utilizing the server port number it was supplied can take direct advantage of additional Internet related 
when the server app manager 650 started the back end ^ services within the enterprise inU-anet, The complexity of the 

process 730. The back end process 730 on the server node PE is determined by the developer's choice. The new Java 

710 may be a distributed system which enca|)sulates an front end S30 includes communication library facilities fr)r 

interface to a Data Base Management System (DBMS) 712. passing messages there between. 

The PE 700 focuses solely on presentation services and its The second step in migrating existing applications to 

own web access capabilities. The ICE-T execution frame- utilize a preferred embodiment is to define the message 

work 724 specifically links the PE 700 to the back end events exchanged between the PE and the back end. The PE 

component 730 usiiig event-driven messages (TCP/IP) 735. and the back end are loosely coupled and exchai^e data 

This design preserves modularity between the PE 700 and events. Each event has a unique name and data associated 

the bade end 730 of an application. with the event. Message event data items arc declared by 

During application execution, the server node 710 ICE-T ^ type, all primitives plus one composite type. Message* data 

com munication librar y 720 manages the cotmection to types directly map to primitive types in both Java and C. The 

facilitatc_ policies that m^imzeac^^to^its'rpour^^ communication hTjraries have APIs which can be used by 

example, a server can be configured tor a maiximur^me to developers to define message events, 

await a transaction re^onse. A timer runs, if it exceeds the The third step is to set up the back cad to handle message 

maximum time before new client messages are received the events. The server resident back end component must handle 

server will terminate the client connection and recycle the message events. This processing is enabled by linking in an 

port. The ICE-T exsgutiQn.fra mework 724 supplies runtime instance of the communication Ubrary with existing server 

err or repo rting .services and applic ati on executioo^d ata code. The communication library has a C API, so the server 

w hich are accessible to system administrators via We b code can be implemented in any language which can call C. 

technologiejsJn. an Internet . Intranet or other network envi- The existing server code utilizes the communication library 

r onment access . When appliration'execution tenninates, the API to send and receive messages. The communication 

relationship between the client node 705 and the server node library calls handler functions in the server code when 

710 also terminates. Application startup must occur each message events come in from the front end. The developer 

time application execution is desired. will create these handler functions and register them, one 

A client's presentation engine 700 can be stored on the handler function per defined message event, using APIs in 

client node 705 and started dynamically if the presentation the communication library. 

engine 700 is cached on the client. The reason for storing the Once compiled and linked, the back end is a single 

presentation engine in cache is to support mobile (nomadic) process >^ich is started by the app manager diuing appli- 

computing, performance and to reduce network trafiSc. This cation initiation. The interface between the server commu- 

techniquc would require vecsioning to assure that the pre- nication library and the server code is multi-threaded, 

scntation engine 700 is synched with the latest, most current The fourth step is to develop a Presentation Engine front 

release on the server node 710. end. Java is utilized for this task. Templates and tools arc 

A DDT ir^A-n/Ma T^c^/cT rvDimcNTT providcd to facilitate this task. The detailed tasks associated 

APPUCAnON DEVELOPMENT facilitating these tasks are described below. 

The application development process in accordance with The final step in migrating an existing client server 

a preferred embodimeat is a system integration task rather application to a preferred embodiment is to install applica- 
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tion cx)iDpoDents od the server node. Both the front end The execution framework 960 is a communication 

(client) and back-^nd components are installed on the server abstraction that utilizes TCP/IP as a communication 

node. A Java startup applet enables clients to access the backbone, and is analogous to a bus in a computer system. 

a]^lication on the server. A set of tools for application Each component in accordance with a preferred embodiment 

installation and configuration are provided as applications s plugs into the execution framework much as various func- 

on server nodes in accordance with a preferred embodiment. tion cards plug into the bus of a computer syston. There is 

A Java startup applet template is also provided to facilitate no notion of local versus remote in the components which is 

development of the application's startup applet. unlike a typical distributed computing environment 

„ In this architecture, there is no distributed domain. Every- 

PRESENTMION ENGINE DEVELOPMEOT Uu„g is local and the that a component connects up ^ll. 

Presentation engine development is the step of developing this framework is by making local caUs to a commuinication 

a new application front-end in Java. To simplify this task and layer whidi is the framework. It's all embodied in the 

provide application performance and robustness guarantees, communication library components. So, the messages that 

all application front ends are instances of a single class of are exchanged between programs are data. Rather than 

programs. A basic presentation engine framework imple- 15 function calls, they are actually data containers. All that can 

mented in Java is provided as an example in accordance with happen in the exdiange is that data are packed up and sent 

a preferred embodiment Developing a specific application as an event, or data are packed up here and sent over there 

presentation engine 'means extending arid customizing the as an event. 

basic presentation engine framework template. A Presenta- Inside of the client and server programs, there are han- 

tion Engine (PE) is itself a system with two components: (1) 20 dlers for the data in the message events. So, any fix)nt end 

a UI implemented in Java, and (2) the PE framework. and any back end has local handlers for a common set of 

Developing a PE is a system integration task with the message events. They can be plugged together by the 

following two steps. framework to create an application. So, what we call these 

(1) Develop a UI which is Implemented with Java. is, "loosely coupled*', which means that there are no depen- 
FIG. 9 is a block diagram illustrating a PE 960 in 25 dencies between the programs and they do not communicate 

accordance with a preferred embodiment. The UI 900 com- directly. This preserves modularity in the ^plication. A 

ponent is developed according to a developer's particular program may send data events, and the program also is 

requirements. Since the front end processing utilizes the enabled to handle data events which interrupt its processing. 

Java language, the UI also takes advantage of Java's rich The framework currently is layered over TCP/IP for a 

functionality. The UI 900 is connected to the PE 960 30 communication vehicle, but other networking protocols can 

framework via an interface to the UI Adaptor 9 10 compo- be utilized. The programs always interact with the ICE-T 

nent. The interface is a general message-passing interface Comm Layer. There is a firewall between the actual, physi- 

that facilitates the attachment of any Java implemented UI cal distributed platform, underneath and the application 

900 with the PE 960 framework to exchange data events. An above because the application components are interfacing 

API is provided to the PE 960 frameworic so that a developer 35 with the abstraction. Thus, applications are independent 

can link the UI 900 to the UI Adaptor 910. from the details of the physical structure of the distributed 

(2) Extend the PE Framework Template (960) enterprise. The enterprise may be scaled, and/or modified 
FIG. 9 illustrates how the PE Framework 960 architecture without requiring re-design of the applications. 

is arranged to facilitate two kinds of external events in i? t t a _j a t»__c j 

-J ... ^ , . . * ! Example In Accordance Wth A Preferred 

accordance with a preferred embodiment The two kinds of 40 Embodiment 
external events are UI events and Message events from the 

Execution Framework. The framework includes a Java P'G, 10 is a block diagram of a prior art client server 
implemented communication library component, the Comm architecture. In the prior art a client computer 1000 would 
Adaptor 950. The PE framework 960 interfaces to the UI access a network 1030 via a predefined data protocol 
900 via the UI Adaptor 910 and interfaces to the server 45 (datastream) and interact with a predefined server 1001 
TCP/IP connection via the Comm Adaptor 950. The media- containing code 1010 and data in the form of a DataBase 
tor 920 component handles all external events moving into Management System (DBMS) 1020. 
and out of the PE framework 960. An application in accordance with an alternate embodi- 
The UI 900, UI Adaptor 910 and the Model 940 are ment is shown in FIG. 11. The encapsulated DBMS 1102 is 
directly extraded by the developer supplying application 50 conserved, as is the enormous investment in code 1170. 
specific infonnation. The communication library and media- However, the server 1180 includes a service API 1160 for 
tor components are not extended by developers. The PE communicating to the network support 1150 which is 
framework 960 has a model 940^view 930^ntroller archi- responsible for turning the web node into a loosely coupled 
tecture. A developer may extend the Model 940 component client 1120 utilizing a small amoimt of Java code and 
in order to imptement local logic and maintain PE-local 5S conforming to a predefined datastream 1130 that is sent by 
state. The view component 930 maps between the Model the server 1180 to the client 1120. A web server 1106 tot 
940 data representation and the message data reprcsenta- receiving HTTP commands 1110 and transmitting Java 
tions. bytecodes 1112 is utilized to facilitate access to and trans- 
It is possible to create a PE framework without extending mission of messages over the web from the server 1180 via 
the Model 940 component of the PE Framework 960. This 60 the access module 1108 and the PE framework 1104 as 
model is referred to as a "PE-lite" option and consists of the discussed earlier and reiterated below, 
comm adaptor 950, mediator 920, UI Adaptor 910 and the FIG. 12 illustrates a server 1210 establishing contact with 
UI 900. To utilize this option, a developer assembles the a chent 1200 through a service API 1200 in accordance with 
components from a UI 900 and a PE framework instance an alternate embodiment. The code 1240 and DBMS 1230 
960. The PE framework 960 makes use of the Mediator 920 65 are as described in FIGS. 10 and 11, However, web contact 
to directly map between UI external events and Comm is established between the nodes using HTTP commands 
external events. 1260 by authenticating a user utilizing the Access Layer 
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1280 to establish client 1200 — server 1210 communicatioD. presentation services. The DBMS interface is encapsulated 

Then, the Java bytecodes 1250 are extracted from the PE in the back end (server). Thus; there are no distributed 

Repository 1290 and downloaded to the client 1200 using transactions which must be handled io the web connection 

the Access Uycr 1280 and the Web Server 1270. between client and server. 

nc. 13 illustrates a loosely coupled client-«eiver appli- 5 FIG. 16 is a block diagram of a ft?mework in accordance 

cation in accordance with an alternate embodiment. The yith an alternate emtodmient. Mo^Uata^OOi^^^ 

Server 1300 communicates via a service API 1360 and "^^J^l^^"^ ^^^^ h t""" ^^^^^^^"^ 

VT ^ J o ^ -ii^A . * ■ modified by a user to add additional data or logic to meet the. 

Network Support 1340 to a Clierit 1330 uUh^g a pre- .etHgrem^ TOanic^ 

DBMS 1310. The loosel/ coupled nature of the apphca- 10 ^^^^ ^^ necessary to b T5ag5d5i-into a fully functional 

Uon architecture is enabled through message commumcation ^^^^^^ provided. The Model data 1 fijWnsjitjHTed on the 

in an asynchronous manner letting the CUent 1330 and the e xternal IF View 1622 and additionalmodcl data'1g2D;m ay 

Server 1300 maintain state independence and connect via a be^ddeia§..ne^ssary to expandJhejaew^Sim^^ 

low bandwidth network 1350. The applications require no message view 16lTcan be expanded by adding additional 

function caU level APFs. 15 ^^^^ ^^^^ ^^^^ message view 1612. Amediator 1630 

Some of the basic architectural design decisions that form is responsible for routing messages and granting control to 

the foundation of a preferred embodiment include the Server the CbmmuoicatioD Adaptor 1640 or the UI Adaptor 1650 >-v ^ - - 

1300 controlling both the Qient 1330 and Server 1300 FIG. 17 iUustrates the basic building blocks in accordance 

states. The Java language is utilized to communicate via the vvith an alternate embodiment. A PE object 1700 is an object 

Web technologies in an Internet, Intranet or other network containing methods (logic) and data (public and private 

envirorunent to distribute Client 1330 state information to information) that is utilized to facilitate a reusable, exten- 

the Client node. The Server 1300 presents an encapsulated sibfe function. APE function 1710 utilizes PE objects 1700 

DBMS interface to the network. The Server 1300 node is to implement callbacks, observers, event handlers and maps 

extended by a framework to support the establishment of a m accordance with a preferred embodiment. PE Info 1720 is 

Client 1330— Server 1300 relationship for web nodes. " ^ basic unit of data moved between functional components. 

The Client 1330— Server 1300 relationship for web nodes and a PE Event Handler 1730 is used by views to handle 

is established utilizing a secure http process ^^ch authen- incoming messages and Ul events in accordance with a 

ticates the user at the requesting node. Then, the Qient 1330 preferred embodiment. 

node is established by selecting an appropriate Client 1330 ^ FIG. 18 is a block diagram hig hlighting the steps utilized 

state &om stored states at the Server, and the Java client state to extend the (PE) framework model 1850 in accordance 

is downk>aded over the network to the particular Client 1330 with a preferred embodiment. A user must modify the UI 

node. Next, the Client 1330 — Server 1300 network commu- Adaptor 1800 as shown at 1810. In addition, user input is 

nication session is commenced by starting the server process needed to modify the Comm Layer 1840, the mediator 1860, 

and establishing a socket connection to the Client 1330 add to the Custom Comm Mechanism 1870 and the Custom 

node. Once the session is established, then the network must Input Mechanism 1880. All of the aforementioned elements 

be managed by maintaining event-driven message passing communicate with each other through Mediator 1860. The 

with the PE communication Hbrary. mediator 1860 communicates, in turn, with Model 1850 

FIG. 14 illustrates an execution firamework 1440 and the through the External IF Mew 1820, whidi can be modified 

system integration task necessary to devebp an application 40 via its section 1822, and Message View 1830, which can be 

1430 in accordance with a preferred embodiment. First, the modified by its section 1856. All of the base processing 

developer defines the message events 1450 that must be necessary to facilitate the application is incorporated into the 

exchanged between components. The client program 1410 basic firamework which provides all of the basic classes for 

and server program 1420 are defined as applications 1430 on instantiating objects necessary to perform user's require- 

the Server Node 1420. The back end must be enabled to send 45 ments. 

and receive messages. The front end (PE) must be FIG. 19 is an illustration of a PE Object 1900 in acoor- 

developed, then the components are installed in the server dance with a preferred embodiment. The PE object is a data 

node 1420. The goal is to support modular application structure library that is used for building the model and other 

development and require minimal additional knowledge sUiictured data passed around in messages. There is an 

burden (e.g. sophistication in Java or OOP) from developers. 50 associated containment hierarchy with primitive 1910 and 

FIG. IS is a block diagram illustrating the modular design composite 1920 objects instantiated from the base PE Object 

of a client application (PE) in accordance with a preferred 1900. An object-oriented architecture facilitates 

embodiment. The applicatirai k)gic 1530 is written entirely polymorphic, encapsulated objects that are fully self- 

in Java to maximize access to Internet facilities. TTie appli- describing and fully enabling for a serialization interface, 

cation logic runs as a Java program or an applet. An External 55 FIG. 20 is an ilhistratioo of a PE Event Handler 2000 used 

Interface Library 1520 contains various callable functions by Views to handle incoming messages and UI events in 

for interfacing to the UI or API 1500 through the UI layer accordance with a preferred embodiment. The PE Event 

1510. A Message Library 1540 provides messages for use in Handler 2000 dispatches tasks based on a name field and 

communicating information through the communication data defined in objects PEIofo 2010 data which is passed 

layer 1550 to the Server 1560. The architecture is a client 60 utilizing a message to implement a map to the model. FIG, 

loosely coupled with the server 1560. DaU exchange is via 21 illustrates a PEInfb object 2100 data in accordance with 

event-driven message passing. A flexible UI 1510 and com- a preferred embodiment. The data encapsulates event and 

munication layer 1550 facilitates message passing APIs message signatures and is used in three places for passing 

interfacing to a Server or UI designs. Developers are not between model and XIF \^cw. Model and Msg View and 

required to understand network communication or system 65 XIF \^ew and the UI. 

programming in order to design and implement applications. FIG. 22 illustrates incoming message flow to a model in 

Hie client program can be designed to support efficient accordance with a preferred embodiment. A message flows 
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into a communication layer in bytestream format 2200 and 
passed via a mediator 2202 to a message view 2210 to 
unpack and dispatch the message utilizing a MsgHandlcr PE 
Event Handler to transfer the PEInfo 2220 data. The PEInfo 
2220 is used to encapsulate the event and message signa- 
tures and transform the message into a model map 2230 
which is thereafter utilized for setValue and geiValue pro- 
cessing 2240. When a UI Event, such as a key press or other 
activity occurs at 2260, a callback PE Function 2270 utilizes 
PEInfo 2280 to pass event and data information to PEInfo 
22W. The PEInfo 2294 is used to encapsulate the UI Event 
signatures and transfonn them into a model map 2292 which 
is thereafter used by PEObject 2250 for further message 
processing the ext^al view dispatcher 2290 for transfor- 
mation into information that the Model PEObject 2250 can 
utilize for further message processing. 

FIG. 23 illustrates incoming messages mapping a UI to a 
Model in' accordance with a preferred* embodiment' in a 
manner very similar to FIG. 22. A message flows into a 
communication layer in bytestream format 2300 and passed 
via a mediator 2302 to a message view 2310 to unpack and 
dispatch the message utilizing a MsgHandler PE Event 
Handler to transfer the PEInfo 2320 data. The PEInfo 2330 
is used to encapsulate the vent and message signatures and 
transform the message into a model map 2330 which is 25 
thereafter utilized for setValue and getValue processing 
2240. When a UI Event, such as a key press or other activity 
occurs at 2350, a callback function 2360 utilizes PEInfo 
2370 to pass event and data information to the external view 
dispatcher 2380 which sends that information, in turn, to 
PEInfo 2382. The PEInfo 2382 is used to encapsulate the UI 
Event signatures and transform them into a model msp 2384 
which is thereafter used by PEObject 2342 for further 
message processing. FIG, 24 illustrates outgoing messages 
mapping a model to messages in accordance with a preferred 
embodiment in a manner similar to FIGS. 22 and FIG. 23. 
In the FIG. 24 arrangement, an outgoing message Aoays from 
set Observer 2440 through the PE Primitive object 2445 and 
essentially reverses the path it took in FIG. 23, being passed 
through PEInfo 2430, Message View 2420, Monitor 2402 
and Cbnomon Layer 2460 where it appears as bytestream 
2400. The reverse flow also occurs with respect to a UI at the 
left side of FIG. 24 where set Observer 2450 passes an event 
message through PEInfo 2460, External View 2465, Monitor 
2402, Penfo 2470, UI dispatcher 2480 and UI Model Map 
2485 to validate UI values. FIG. 25 illustrates outgoing 
messages mapping a model to a UI in accordance with a 
preferred embodiment in a manner simOar to the foregoing 
Figures. In the FIG. 25 arrangement, an outgoing UI mes- 
sage flows from set Obsenrer 2550 through the PE getValue 
object 2255 and essentially reverses the path it took in FIG. 
23, being passed though PEInfo 2560, External Mew 2570, 
Monitor 2572, PEInfo 2580, UI di^atcher 2590 and UI 
Model Map 2595 to validate UI values. The reverse flow 
also occurs with respect to a message at the right side of FIG. 
25 where set Observer 2540 passes an event message 
through PEInfo 2530, Message Mew 2520, Monitor 2572, 
PEInfo 2470 and Cbmm Layer 2510 firom which element it 
exits as message bytestream 2500. To further clarify pro- 
ces^g in accordance with a preferred embodiment, the 
detailed installation and logic qpecificatton for an plica- 
tion in accordance with a preferred embodiment is presented 
below. 

Enterprise computing environments usually consist of 
many kinds of nodes interconnected by a network. In a 
typical environment, a server node in the network holds data 
and programs that interact with the database, and a climt 
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node contains a program or programs for accessing the 
information on the server. The complexity of these environ- 
ments makes it difficult to create, configure, deploy, and 
administer software applications. The advent of Web tech- 
nologies (browsers, the Java language, HTTP) has enabled 
enterprises to create and use internal Webs to help solve 
some of these problems. RG. 26 illustrates an arrangement 
that facilitates the launch and utilization of an application 
URL in accordance with a preferred embodiment. When the 
application URL 2615 is started, the client node 2600, 
through its browser 2605, executes startup applet 2610 to 
thereby collect information about the client user and contact 
the server node 2620. The server node 2620 includes a server 
program 2625, a database 2630, and access layer 2635, and 
application manager 2640, a web server 2645 and presen- 
tation engines 2650. The details concerning launch and 
utilization of application URL 2635 can be found in the 
discussion of FIG. 6 above 

Java enables the Web as a client-server application plat- 
form and distribution channel. The "Interprise" Computing 
Environment Toolkit (ICE-T) enables building, extending 
and deploying client-server applications for the Web. 
C'lnterprise" combines the internet and the enterprise.) 

The ICE-T application provides: 

A toolkit for creating client programs that can be down- 
loaded on the Web 

Interfaces for enabling a server program to work with a 
client as a single application 

The tools to connect both client program and server 
programs to a framework for executing them 

Tools for installing, deploying, and administering appli- 
cations 

ICE-T Applications 

An application consists of a server program component 
(implemented in any language that can call C) and a client 
program component (implemented in Java). The client com- 
ponent consists of a GUI and a Presentation Engine (PE). To 
complete the application system, ICE-T provides a Com- 
munication Layer that enables the exchange of messages 
between the client and server components, an Exception 
Layer for error reporting from ICE-T components, and an 
Access Layer for managing how applications are deployed. 
The task of the ICE-T application developer is to assemble 
the components into an application system. 

ICE-T provides Java client access to server applications. 
New applications or existing ones extended utilizing a 
preferred embodiment Among existing applications, those 
that are partitioned so that server programs (business logic) 
and databases are on the server, and user interfaces are on the 
client (three-der client-server applications) are especiaUy 
suited for migration to ICE-T front ends. 

ICE-T is especially suited for enterprise applications that 
require: 

Access to department or corporate data without changes 
to databases or the programs that access them. 

For enterprises already using an enterprise web technolo- 
gies in an Internet, Intranet or other network 
environment, ICE-T applications can provide quick 
access to existing data from anywhere in the organiza- 
tion or the field where there is an internet connection. 

Qient platform independence. 

ICE-T Presentation Engines can run anywhere the Java 
^ual Machine is present. 
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Rapid developmeat. 

QicDts are developed in Java using a null application 
template that contains the necessary Java classes and 
methods for integration with a GUI and a Communi- 
cation Library. 5 

Easy deployment. 

ICE-T provides scripts and tools for installing and deploy- 
ing applications, include a generalized startup ^plet 
for providing application launch from a Web browser or 
applet viewer. 

Centralized authentication of users. 

A customizable Access Layer, installed on the server, 
enables centralized control of access to client pro- 
grams. 15 

Easy maintenance. 

For most enterprises, maintaining existing applications is. 
a tremendous resource burden. ICE-T provides the 
means to make new application front>cods (clients), or 
migrate existing ones, without changing the architec- 
ture or programs of the back-end (server), or requiring 
a steep learning curve. 

y/idt use throughout the enterprise, from the desktop or 
the laptop. A familiar and pervasive interface. 25 

Eod-users can name ICE-T applications as applets in a 
Web browser. 

ICE-T ^>plication Development and Deployment 

The primary development task in an ICE-T application is ^0 
to create an application front end, a Java Presentation 
Engine, from the provided template. The Presentation 
Engine (PE) template includes methods to send messages 
and their data through a client Communication Library. 
Developers modify the template to specify the messages and 
data required for their appUcatk)n. The Communication 
Library handles the passing of messages and data across the 
network. The Presentation Engine Toolkit supports these 
tasks. The Toolkit is a full set of Java components some of 
which you must modify or extend. 40 

An additional development task is to modify the server 
program to specify which function to call in response to 
inbound messages and make calls to a server Communica- 
tion library to send results to the client All of the compo- 
nents in an ICE-T application system reside on the server. Td 
deploy an application, you install its components and addi- 
tional ICE-T files and programs that manage applications on 
the server. ICE-T also provides a template for creating a 
startup applet that enables users to start q)pUcations from a 
browser. Chapter 3, "Configuring and Deploying ICE-T 
^plications" describes these tasks and tools. 

Event-Driven Message Passing in ICE-T 
Applications 

55 

The components of ICE-T applications create, send, and 
receive messages in response to external events. An event is 
a way of communicating that something has happened, such 
as input from the user (a mouse elide) or a change in the 
system environment (a server shutdown). 

Hie ICE-T Communication Layer enables asynchronous 
event-driven message passing between client and server 
program components on TCP/IP. In ICE-T, the messages 
themselves are events, and each program component 
includes local handlers for message events. 65 

Qient and server program components must each be set 
up to create, send, and receive messages. Part of the Pre- 
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sentation Engine's functionality is to determine the recipi- 
ents and deliver the messages to them. For example, the user 
interface sends a message to the Presentation Engine when 
a user clicks a button. The Presentation Engine receives the 
message and then either sends it to the data model or the 
server program, which then performs an operation and 
replies with the result. 

The server program must also be able to receive messages 
and must register functions to handle them. 

The recipients of messages do not need to know much 
about each other, they just need to specify what messages 
they want to receive. This information is registered using the 
createMessageHandlers 0 method in the client program and 
the createMessageHandlers ( ) function in the server pro- 
gram. 

Presentation Engines should include handlers for two 

kinds of application events: - 

Events from the user interface 

Events coming in to the Presentation Engine from the user 
interface result in messages to the server or the Pre- 
sentation Engine's data modeL 

Events from the server 

Events coming in to the Presentation Engine from the 
server result in displaying data in the user interface or 
putting data in the Presentation Engine's data model. 
Server programs should include handlers for messages 
from the client. Typically, the handler would call application 
logic and send the resulting message and it's data back to the 
client through the server Communication Library. 

ICE-T .^plication Execution 

ICE-T apphcadons are designed to work within existing 
client-server environments. They differ from familiar client- 
server appUcations in some key ways. 

Typically client programs are developed, maintained, and 
distributed periodically, taking long cycles of development 
time, and requiring time to deploy to chent nodes. Users who 
are not on a node on the distribution route may miss software 
updates. Development can consume resources because of 
the difScuIty of the language or tools used. 

Compiled ICE-T Presentation Engines arc installed on the 
server and downloaded on request through HTTP servers. A 
pair of Communication Libraries behave as a framework for 
executing the application. This communication layer 
handles the marshaling and umnarshaUing of the message 
data transferred between client and server. Both client and 
server ^ould be prepared to handle shutdown events. ICE-T 
provides default shutdown handlers for this purpose, and 
developers can add their own. 

How ICE-T y^hcations Work 

Before developing an ICE-T application, you might find 
it useful to see how ICE-T applications work, from both an 
end-user's perspective and inside ICE-T. 

The User View 

ICE-T applications can use a Java-enabled Web browser 
for client access to application execution. Although devel- 
opers may choose to have applications launched outside a 
browser, a Web page presents a familiar and easy to use 
interface for launching applications. 

The user begins by opening a Web page and clicking on 
the URL for the apphcation she wants to run. The URL is the 
address for a Web page that includes an ICE-T application 
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Startup applet. The Web page with the startup applet is 
loaded into the browser. The applet collects access informa- 
tion from the user. The applet contains the URL of the server 
holding the appHcation components and the application 
name. This information is processed on the server. If the user 
name, password, and chosen application are authorized, the 
server downloads a Presentation Engine to the user's node. 

The Presentation Engine presents the user with an inter- 
face for interacting with the server program and data. It also 
determines where to pass messages for handling, either to 
the server program or to its own data model. One example 
of a client program is one that communicates with a server 
program that searches a database, for example an employee 
database. Such a client program might have these user 
interface elements: 

A text field where users enter a first or last name that they 
wish to find in the employee names database 
- ~ - Buttons for dearing-the fields (Clear),* exiting the appli- 
cation (Quit), and launching the search (Search) 

A scrolling window for viewing the tesuUs of the query 

The user enters a first or last name and presses Return or 
clicks a Search button. The client program sends the query 
to the server, where the server program searches the 
employee database for a matching name. If a match is found, 
the server returns the results to the client. The results are 
displayed in a window on the client. 

The ICE-T View 

When a user launches an ECE-T application, the client 
node establishes a Web connection with the server node 
using HTTP. The server manages this Web connection. 
ICE-T applications can be laimched from a browser, an 
applet viewer, or as standalone applications. FIG. 26 illus- 
trates the steps associated with launching an application 
URL in accordance with a preferred embodiment On the 
server side, the ICE-T Access Layer (a pgi-bin executable) 
authenticates the user data. If the authentication succeeds, 
the Access Layer contacts the ICE-T i^jplication Manager 
and the implication Manager starts the server program and 
initiates a network session. 

The i^>plication Manager downloads an HTML page with 
a startup applet for the application. When the user runs the 
startup applet, the Application Manager selects a compiled 
Presentation Engine and downloads an HTML page con- 
taining the applet tag for it to the chent using HTTP. The 
compiled Presentation Engine includes a GUI and an 
instance of the client Communication Library and is ready 
for execution in a Java-enabled browser or anywhere the 
Java Virtual Machine is installed. 

The client node then executes the Presentation Engine 
locally. The Presentation Engine makes a TCP/IP connection 
to the server where the server program is ruiming, and the 
client and server programs cooperate to execute the appli- 
cation. 

When a user inter&ce event occurs^or example, when 
the user enters a first name in the text field and clicks a 
Search button — the user interface passes a message to the 
Presentation Engine. The Presentation Engine either sends 
the message to its data model for prooessii^ by the client, or 
passes the message to the server for processing by the server 
program. The Presentatioa Ei^jne determines where on the 
client a message is handled based on how you have regis- 
tered message handlers. When the server program sends a 
messagp with data to the client, the Presentation Engine 
displays the result. 

The exchange of messages between client and server is 
handled through the ICE-T Communication Libraries in the 
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ICE-T Communication Layer. When the client program 
terminates, the Application Manager closes the socket con- 
nection to the client and terminates any server processes it 
started, 

^ ICE-T Task Summary — Building Program 

Components 

ICE-T's modular architecture makes it easy to distribute 
development tasks to multiple developers. Alternatively, a 

10 single developer can complete ICE-T development tasks in 
stages. Developing a client program requires making a Java 
Presentation Engine, connecting it to a user interface and to 
the ICE-T Cbmmunication Layer so that it can communicate 
with a server program The server program could be an 

IS existing program or a new one. It must be written in a 
language that can call C so that it can work with the ICE-T 
Communication Layer. You don't need to develop new 
server programs for ICE-T applioitions, but you iiiiist enable" 
the server program to handle messages from the client. 

^ ICE-T Application Building Blocks 

An ICE-T application consists of a client program and a 
server program communicating through a Communication 
Layer. The client program consists of: 
25 A GUI built with Java 

A Java Presentation Engine built using a template. 

These components, and related classes used by the Pre- 
sentation Engine, combine to behave as a single client under 
the control of the Presentation Engine. The Presentation 
Engine may be presented as an applet launched firom an 
applet viewer or a Web browser, or as a standalone appli- 
cation. 

The server program, new or existing, is developed how- 
ever the developer chooses. It must be in a language that 
calls C and it must include functions for handling messages 
firom the client. A template with these fimctions is provided* 
as is a main routine that makes calls to the provided server 
Communicatioa Library. 

ICE-T provides these templates, tools, and libraries for 
^ developing applications: 

pe_template.java 

A template for a working Presentation Engine. 

ICE-T packages (supplementary to the standard Java 
^5 packages) 

server-template.c and server_template.cc. 

Server program templates (one each for C and C-M-) that 
define and enable message passing to and from the client. 
The templates can be used with existing programs or used as 
5Q a starting point for developing server programs. These 
templates are analogous to the pe_template used for the 
client. 

ICE-T message data types that work the same on both 
client and server. 
55 ICE-T also provides a framework that the developer does 
not modify and in ^ich ICE-T applications can execute. 
This framework includes: 
Communication Layer 

Supports network communication between client and 
60 server programs. The server Communication Library pre- 
sents a C API to the server program, which is linked to this 
library. The client Communication Library is implemented 
in Java. 

ICE-T Exception Layer 
65 Provides exception reporting from the ICE-T application 
(client and server) in addition to standard system error 
repeating. 
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The Presentatioa Engme 

Every Prescatation Engine extends (inherits from) a Java 
class named PresentationEngine. All of the objects that the 
client program needs are either in the Presentation Engine 
class or called by it. ICE-T provides a class that extends Java, 
and calls the methods that you need to create a working 
Presentation Engine. 

The filename for the Presentation Engine template is 
pe_template.java. You can find it in the ICE-T application 
installation directory under Templates/C or Templates/C++. 
The file is placed in each of the Template subdirectories for 
convenieDoe. The pe_template is the same io both files. 

FIG. 27 is a table whidi describes the forms of a Presea- 
tation EngiDe, as ao abstract Java class, a template for 
development, and an executable component in an applica- 
tion in accordance with a preferred embodiment. 
^ " to create a working Presentation Engine, you copy the 
pe_template file and make these changes: 

Supply your own Presentation Engine name. 

Create user interface components or map the ones from a 
Java GUI builder. 

Create a data model (if your application requires client- 
side processing). 

Define messages and their handlers. 

Register message handlers. 

These steps are described in this chapter. 

Presentation Engine Implementation Options 

Developers can create Presentation Engines that simply 
send messages from the user interface to the server and 
display the data that the server returns on the client. This 
option for Presentation Engine implementation is called a 
''PELite." An altemative implementation of Presentatioa 
Engine handles some local data storage in what is called the 
Presentation Engine's data model. For the latter, developers 
are required to implement a createModel( ) method, 
described in this chapter. Both options are supported by the 
pe_templatc. 

ICE-T Classes and Packages 

The documentation for the ICE-T Presentation Engine 
API is presented in HTML form, like the Java API 
documentation, and is accessible from the following URL: 
file :///<ICE-T InsUUation Directory>/doq/api 
where <ICE-T Installation Directory> is the name of the 
directory on your system where you have installed ICE-T. 
The C and C+-i> header files used by the server program are 
in the ICE-T installation directory under Server. 

ICE-T Message Data Types 
ICE-T message data types: 

Can be used to construct the data model in the Presenta- 
tion Engine 

Are available for use in the server program for use in 

application logic 
Have analogs on both the client (Java) and server (Q 
Use basically the same APIs on both the client and server 
Can contain only other ICE-T data types 
Are used in messages from cb'ent to server, and server to 

client, where they will appear as a local data structure 

of their analogous type. 
The table appearing below describes the primitive ICE-T 
message data types and their analogous types on client and 
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server. The prefixes Pe and Srv are provided for your 
convenience in naming things. They are handled as the same 
type by ICE-T. 



Data IVpe Client {PE) Seiver (Q 



Petbar, SrvChar 


char (Unicode) 


char(C) 




16 bits] 


8 bits 


PeString, SrvString 


string 


char* 


PeBoolean, SivBoolean 


Boolean 


int 




16 bits 


1 byte 


Pelnteger, Sivlnteger 


int 


int 




32 bits 


32 bits 


PeLoQg, SrvLong 


long 


long 




64 bits 


64 bits 


PeFloat, StyFloat 


float 


float 




32 bits 


- - 32 bits 


PeDouble, SM>ouble 


double 


double 




64 bits 


64 bits 



1. ICE-T transmits only the ASCII (8 bits). 

ICE-T supports a composite data type based on the Java 
vector class (java). util. Vector). It differs from the Java 
25 vector type in that it provides an implementation that works 
on both sides of the ICE-T application (Java clients and C or 
C++ server programs), and it only takes ICE-T primitive 
data types. 
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TABLE 




ICE-T VfectorTVoe 


Dataiype 


Description 


Pe^ctor, 


A collection that iinpleinents a variable-length anay. 


sty Vector 


Add elements sequentially with the add Element 




( ) method. Access an element by its index. 



Working with the ICE-T Directory Stnicttire 

40 

Before developing applications, copy the provided tem- 
plates and Makefiles to an application development direc- 
tory. There are two subdirectories of templates. 

<ICE-T Installation Directory>/Templates/C 
45 Contains Example, mk, pe_template.java, and server__ 
template .c. 

<ICE-T Installation Directory>/Templates/Cplu^lus. 
Contains Example .mk, pe^template.java, and server_ 
template, oc. 

50 For example, create an application directory for an appli- 
cation named myAppName in which the server program is 
written in C++, and copy the templates to it: 
% mkdir myAppNams 

% do <1CE-T Installation Directory>yTemplates/C++/ 
55 *<1CE-T Installation 

Dircctory>/i^)plications/myAppName/. 

The ICE-T installation scripts and MakeHierarchy depend 
on the newly created application directory being two levels 
below the ICE-T installation directory. If you choose not to 
^0 follow the directory semp suggested by the example, you 
will have to supply options or arguments indicating where 
the ICE-T installation directory is in relationship to the 
directory you have created. 

g5 Designing the Client Program 

Here are some design decisions to make before you 
develop the client program for an ICE-T application. 



11/19/2003, EAST Version: 1.4.1 



6,052, 

33 

Using a graphical user interface (GUI) toolkit, specify and 
design the user interface. 

Determine the events the client and server components of 
the application should handle. Name each of these 
events and associate data with it In this step you ^ 
acKwer the question of what messages will be passed 
between the Presentation Engine and the user interface 
and between the E^sentation Engine and server. 

Decide what application logic to put in the client program, 
if any. 

Decide what, if any, data processing you want the client 
program to handle. This affects whether you create event 
handling for data updates in the Presentation Engine or just 
use the Presentation Engine as a mediator between the user 
interface and the server data (a "PE lite"). 

Specify how the user interface should be updated when 
- ^ the Presentation- Engine receives messages and data 
from the server. 
Specify how the Presentation Engine receives and 20 
decodes data from the server and whether it stoies the 
data for later retrieval or di^lays the data directly. 
If you choose to store data in the Presentation Engine, 
specify how it is to be stored and updated and what 
other components in the application depend on that 25 
data. 

Developing the User Interface 

You can create the user interface for the ICE-T application 
at the same time as, or before, you create the Presentation ^ 
Engine. Even though they can be separate, the Presentation 
Engine and user interface work together, so the interactions 
between them should be planned. 

Creating a Presentation Engine 35 

Create a Presentation Engine involves the following basic 
steps that arc described in detail throughout this section: 

1. If you have not done so already, copy one of the 
Ibmplates subdirectories to the ^plications directory. ^ 

The ICE-T installation directory includes a communica- 
tion directory for developers to use. To create applications, 
make a subdirectory under applications for each ICE-T 
application you develop. 

2. Modify and rename the pe_plate file to suit the 45 
application. Use the same name for the class and the file. 

3. Create a Presentation Engine class. 

Create your own Presentation Engine definition using 
pe_templatc.java. 

4. Integrate the Presentation Engine with the user inter- 
face (GUI). 

Create a separate user interface class using your chosen 
Java tool. Integrate the GUI with the Presentation Engine by 
implementing the createUI ( ) method that is found in 
pe^templale.java. 

''Working with the ICE-T Directory Structure" describes 
how to implement createUI( ). 

5. Determine and define the message events to be passed 
between the Presentation Engine and server program and the 
Presentation Engine and user interface. 

Name each of these events and associate data with it. 

Specify the type of data that will be passed in response to 

each message event. 

a. Add handlers for events on GUI components. 65 
Implement the operations you want the application to 

perform in rc^nse to user interface events. 
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b. Write the code for handling incoming message events 
in the Presentation Engine. 

Define handlers in the Presentation Engine for incoming 
messages from the GUI. Define handlers in the Presentation 
Engine for incoming messages from the server. 

Developers can choose to write a separate class, or 
classes, in separate files to handle events, lliis means that a 
named handler can be modified without modifying the 
Presentation Engine framework itself. 

6. Register which handlers will be sent whidi messages 
when events occur (map messages to handlers). 

Specify what handler should receive each message. 
''Registering Handlers" describes this step. 

7. Build the Presentation Engine. ICE-T provides a make- 
file to build both server and client programs. 

These activities are analogous to the tasks for modifying 
server programs to work with clients. In both client and 
server program cases,' ICE-T provides templates with' meth- 
ods (Presentation Engine) and functions (sersrer) for regis- 
tering handlers. Developers provide only the application- 
specific messages and data. 

Creating a Presentation Engine Oass 

Copy one of the Templates subdirectories to the Appli- 
cations subdirectory. There are two subdirectories, one for C 
and one for C-H-. For example, create a directory for an 
application named myAppName. If the server program for 
myAppname is to be writtoi in C, copy all of the files from 
the Templates/C directory: 
% inkair my^pName 

% cp <ICE-T Installation Directory^/Tranplatcs/C/* 
<ICE — T Installation Directory>/Applications/ 
my^)pName/. 

For each Presentation Engine you create, modify 
pe_Jemplate.java to declare a class that extends the abstract 
Java dass PresentationEngine: 

public class myPresentationEngine extends Presenta- 
tionEngine {//methods for your application} 

Note — Be sure to give the class and the file the same 
name. For example, if the Presentation Engine class is 
named myPresentationEnqine, the file should be named 
myPresentationEnqine.j ava. 

pe_template.java contains the class and method declara- 
tions that you implement to provide the functionality you 
want. 

The methods must include: 
createul ( ) 
creatcModel ( ) 
createMessageHandlers ( ) 
initializcApplication ( ) 

Implementing createModel ( ) and initializei^lication ( ) 
is optional. 

You do not have to use initializeApplication ( ) unless 
your client program requires local initialization before com- 
munication is started. 

Importing Packages 

The pe_template imports the appropriate packages, 
including these ICE-T packages and standard Java packages: 
sunsofl.ice.pe 
sunsofl.ice.pe 
java.net 
java.io 
java.applet 
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java.util 
java^wt 

Iht Java language package Uava.laqg) is implicitly used 
and does not have to be explicitly imported. 

To include the required packages, a Presentation Engine 
class must have these import statements. Don't delete them 
from the pe^template. 

import sunsoft. ice,pe. 

import Java .net ^; 

import java.io.; 

import java .applet.*; 

import java.util.*; 

import java.awt.*; 

Integrating the User Interface with the Presentation 
Engine _ 

ICE-T apph'cations must make user interface elements 
from the application GUI available as components that the 
Presentation Engine can access. The Presentation Engine 
reads and handles data from events in the user interface and 
updates the user interface with data returned from the server. 

Creating a GUI that is separate from the Presentation 
Engine, offers developers more flexibility because updates 
to the GUI do not require major changes to the Presentation 
Engine. Use the createUI ( ) method to make the GUI 
components available to the Presentation Engine. 

To implement the createul ( ) method with application- 
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Engine, you use the createModel ( ) method to create the 

data objects (Observables) to bold the data and attach 

Observer objects to them. 
createModel ( ) is optional and is commented out in the 

pe_jemplate. To use createModel ( ): 
Uncomment the method in the Pe__template 
Create Observable data objects to hold data from the 
server 

Attach Observers to the data objects, if necessary 
Put the Observable data objects into the data model. 
This example instantiates a Pe Vector data object named 
empvector. Using the Observer and Observable methods is 
desCTibed in "Attaching Observers to Data Objects." 
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protected void createModel () { , 

//create the observable 

PeVfector es^Vector - new PeVectoi( ); 

//Attach observer to the observable 

emp'Sfector. addObserver (new empObserver (model)); 

//put the observables into Model 

model. ftddObscrvable ("emp^ctoi", empVbctor); 

} 



25 



Attaching Observers to Data Objects 

Developers have the option of defining any data objects in 
the model as a simple PeObject (a data item that is sent in 



messages) or as a PeObservable, a data item with a method 
specific operations, write a body for the method in which associated with it A PeObservable is a data object with an 

associated PeObserver function that is called when the data 



you: 

Declare variables for the user interface elements 

Create a frame to hold the GUI applet (optional) 

instantiate and initialize the GUI applet 

Get the user interface components 

Provide initial values for fields in the GUI (optional) 

Add the GUI elements to a Container object (provided in 
the PresentationEngine dass) 

For example, here is excerpted code from a createUI ( ) 
method that dcclaies variables for labels and text fields, 
creates a frame, and adds the user interface elements to a 
container component defined in the PresentationEngine 
class. 
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protected void createUI () { 

Label Iabcl_l, Iabel_2, labeLJ; 

TbxtFicId textFicld_l, te3itRcld_2, textField^; 

//... additional variables 

fr - aew Frame C*My AppUcatioa TUle"> 
feadd CCenlei^, ui); 
fir.pack ( y, £r^how( ); 



//... 



te3itFicld_l jclText (** "); 
teztField_2.senbxt (" 

mContai]ier.addObiect (" fiiatName", textneld_J); 
iiiContainer.addOt)ject lastName", te3aFteld_2); 
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Creating a Data Model in the Presentation Engine 
(Optional) 

Updates to the client program can be sent to the user 
interface or to the data model in the Presentation Engine. If 
your application is designed to hold data in the Presentation 



is updated. If a data object changes state, and you want the 
application to notify any program components that depend 
on that data, you define each data object as a PeObservable 
and you attach a PeObserver to it. 

ICE-T provides the peobservable and PeObserver classes. 
Developers call the methods in these classes to add observ- 
able data objects to the model and add heir observers to an 
observer list. 

Handling Events 

ICE-T client programs receive messages in response to 
external events. Client program developers need to specify 
what messages they want the Presentation Engine to receive 
and roister this information using the createMessageHan- 
dlers ( ) method. Server program developers have the 
analogous task of defining message handlers and registering 
their handlers. 

ICE-T provides a layer of abstraction to handle interac- 
tions between the GUI and the Presentation Engine. This 
layer is called the UI Adaptor and it is a set of Java classes 
that developers use as given. The Presentation Engine makes 
calls to the UI Adaptor to register messages. The 
Pe_template includes the necessary methods; developers 
provide the message bodies as described in the procedures in 
this chapter. 

Presentation Engines handle two kinds of application 
events: 

Events from the user interface 

Events coming in to the Presentation Engine from the user 
interface result in messages to the server or the Pre- 
sentation Engine's data model. 

Events from the server 

Events commg into the Presentation Engine from the 
server result in displaying data in the user interface or 
putting data in the Presentation Engine's data model. 
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Handling Events from the User Interface 

Applications handle user interface events, such as button 
clicks and text entry. Java provides an action ( ) method for 
associating actions with events^ such as those on user 
interface components. 
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This example from the pe__template shows the definition 
for a class named SampleUIHandler. The constructor 
method passes adaptor and ui Container as arguments to gjve 
your execute method access to them. 

Use this definition as is, but supply the name of the class 
and add the body of the execute method: 



public boolean actiott(Event evt» Object aig) { 

//... 10 
} 



Typical behavior for an action ( ) method is to get the data 
from the user interface event and send a message to the 
component of an application that is designated to handle it. 
In an ICE-T application, those messages are sent to the 
Presentation Engine using the sendMessage ( ) method. 

Here is an example of an action ( ) method when in a GUI. 
It handles an event in which the user clicks a ''Search'* 
button after entering a text string 



public boolean actioit(EveDt cvt, Ohjtd atg) { 

//. . - 25 
if (arg. equals ("Search")) 

{ 

System .out.prmtlaCScarch event is detected"); PeString firstName 

- new Pcstring (entry^l.^lTtott ( )( ); 

PeMessage msg - new PeMessage (^Search^*); 

msg. ftddbataEleinent (fiistName); 

Pel>ebug.primln(*-" msg is: ''+insg); 

//send this event to the UI adaptor 

pcsendMessagp (msg); 

} 

return tme; 



The action ( ) method sends the message defined in: 

PeMessage msg-new PeMessage^Search"); 

The PeMessage class encapsulates the message name and 
the data. The data in this message, added by the addDa- ^ 
taElement ( ) method, is a first name. The sendMessage ( ) 
method seink the message and its data to tbe Preseotation 
Engine through the PeUIAdaptor, a class that ICE-T pro- 
vides for handling communication between the user inter- 
face and the Presentation Engine. Developers do not need to 
modify PeUIAdaptor, but do call methods in it as directed by 
the pe_template. 

Handling Events from the Server 

Events from the server program that generate messages 
for the client can be handled by: 

Updates to the user interface 

Updates to the Presentation Engine data model. 

Write a handler for each event from the server. Inchide it 55 
in the same file as the Presentation Engine, or a separate 
class file. If you use a separate file for the handler, remember 
to define it with public access. 

Creating Handleis for Updates to the User Interface 

60 

To create a handler that updates the user interface, use the 
template to define a class that extends PeUIHandler. PeU- 
IHandler is an abstract class for a handler of messages that 
are sent to the user interface. 

The constmctor method in PeUIHandler provides access 65 
to the uiContainer for updating the user interface and for 
sending messages using the uiadaptor. 



class SampleUIHandler extends PeUIHandler { 
public SampleUIHandler(PeU1Adaptor adaptor, PeUI uiOontainer) { 
super (adaptor, uiContainer); 

public boolean execute (Object caller, PeMessa^ message) { 
//decode the record sent by the server 

//update the ui 
return true; 
} 



To enable the Presentation Engine to know what messages 
to send to SampleUIHandler, register the name of the 
handler and tbe data it handles. This step is described in 
"Registering Handlers for Updates to the User Interface". 

Creating Handlers for Updates to the Model 

Messages from the server can be handled with code that 
updates the GUI (as in the example above), or code that 
stores the data in the Presentation Engine. If you used the 
createModel ( ) method, you have to create handlers for the 
events that affect the model. 

To create a handler that updates the model, use the 
template to define a class that: 

Extends PeModelHandler. 

PeModelHandler is an abstract class for a handler of 
messages that are sent to the data model you defined 
with createModel ( ). 
Uses the constructor of peModelHandler as is, except to 
use the new class name in place of PeModelHandler. 
public PeModelHandlei(PeModel model) { } 
This constructor passes the model class as an argument so 
that your Presentation Engine has access to the model class 
for updates. 

This example firom the pe_template shows the definition 
for a class named SampIeModelHandler. Use this definition 
as is, but supply the name of the class and add the body of 
the execute method: 



class SampIeModelHandler extends PeModelHandler { 
public SampIeModelHandler (PeModel model) { 
super (model); 

} 

public boolean execute (Object caller, PeMessage message) { 
//Application code that decodes the record sent by the server 

//Application code that updates the model 

return true; 

} 

} 



Registering Handlers 

Register what component handles what messages in the 
Presentation Engine by filling in the createMcssageHandler 
( ) method. 

createMessageHandler () is defined in the pe_template to 
register handlers with either the user interface or the model. 
Use this method as defined, changing the arguments for 
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adding handlers to supply the names of the messages and 
handlers you defined. 

Registering Handlers for Updates to the User 
Interface 

This code snippet from the Pe_Jemplate illustrates how to 
register the handler defined in the example in "Creating 
Handlers for Updates to the User Interface". 

Note that you just use the code in the example as is. You 
don't need to specify anything other than the names of the 
messages and the objects that handle them. For each handler 
you register, add a call to the uiAdaptor. addHandler ( ) 
method. Change the arguments to the uiAdaptor.addHandler 
( ) method to specify the names of the messages and handlers 
you defined. In this example, the name of the message is 
"sample_ui_message" and the name of its handler is Sam- 
pleUIHandler ( ): 



protected void cieateMessageHandlers ( ) throws 
Duplicatel&ndlerExoeption { 

mAdaptoraddHaodler ( "sample.uL^essage", 

new SampleUIHasdler (uiAd^tor, uContainer) ); 

//... 



uiAdaptor and uiContainer are defined by the Presenta- 
tionEngine class. Your handler needs to pass them as argu- 
ments so that its execute method has access to the user 
interface elements (GUI components). 

Registering Handlers for Updates to the Model 

If the message is to be handled in the Presentation 
Engine's data models register the name of the handler in the 
model. This code is defined for you in the pe_template. 

This code snippet illustrates how to register the handler 
defined in "Creating Handlers for Updates to the Model**. 
Use the code in the example as is. Change the names of the 
messages and the methods that handle them: 



protected void createMesst^eHandkn ( ) 
throws DuplicateFbiidIerExcq;)tioii 

model. addHaodla ('^u]z^le_inodeL_jnessage*', 
new SampleModellbiidler (model)); 

/A.. 

} 



Handling Shutdown Events 

ICE-T provides default shutdown handlers. The shutdown 
handlers are defined in the PresentationEngine class, not in 
pre_template. Developers who do not want to accept the 
default shutdown handling can write their own shutdown 
handlers. A new handler takes precedence over the previous 
handier for the same message name. To add a new handler, 
developers: 

Write the handler 

Use the same message name ("ICET_SHUTDOWN") 
Use the methods provided for registering handlers in the 

Presentation Engine and the server program. 
When a shutdown happens, the Communication library 
notifies the application by means of the shutdown handlers. 
Shutdown handlers are identical to other message handlers, 
but have a preset message name (**ICET_SHUTDOWN"). 
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To register a shutdown handler, the application code makes 
a call to addMessageHandler ( ) using the preset message 
name. 

Registering Shutdown Handlers in the Presentation 
Engine 

An application can register two shutdown handlers in the 
Presentation Engine, one with the UI Adaptor and one with 
the model. Registering shutdown handlers in the Presenta- 
10 tion Engine is optional. 

To register a shutdown handler on the uiAdaptor, use the 
following call: 
UiAdaptor.addHandler ("ICET_SHUTDOWN", new 

shutdownHandlerUI (uiAdaptor, uiContainer)); 
To register a shutdown handler on the mode], use the 
following call: 

' 'nwdcUddHaiidlef ("ICET_SHUTDOWN", new shut- 
downHandlerModel (model)); 

20 

Registering Shutdown Handlers in the Server 
Program 

Your application can register one shutdown handler with 
the server program. 

25 

To register a shutdown handler in the server program: 
SrvComm_addMcssageHandlcr ("ICET_ 

SHUTDOWN", 
<functionPointerToShutdownHandler>); 
30 Provide the name of the function that executes when the 

shutdown occurs, 
(<functionPointerToShutdownHandler> in the example 

above). 

35 Preparing the Server Program for Communication 

To prepare the server program to commimication with the 
client program, the developer '^phigs in" the server program 
to ICE-T's Conmiunication Layer. Connecting the server 
program to the server Communication library, which is part 

^ of the ICE-T Communication Layer, is analogous to con- 
necting the GUI to the Presentation Engine. In both cases, 
developers enable the exchange of messages, and these 
messages are handled bcally by the components—the server 
program component and the Presentation Engine compo- 

*5 nent 

The server program component in an ICE-T application 
must be written in any language that can call the C pro- 
gramming language. ICE-T provides both C and C++ lan- 
guage templates for handling messages and making calls to 
the server Communication Library. Use the appropriate 
template to start a new server program in C or C++, or add 
the template functions to an existing server program. 

Note — ^If you have not done so already, copy one of the 
Templates subdirectories to the i^lication subdirectory. 
There are two subdirectories, one for C and one for C++. 
Each directory contains a server_template, one for C and 
the other for C+4-. 
To enable communication between the server program 
gQ and the client program: 

Create message handlers in the server program that are 
analogous to the message handlers you created in the 
Presentation Engine. This step is described in "Han- 
dling Messages in the Server Program". 
65 Make calls to the ICE-T server Communication Library, 
The server program templates provide functions for mes- 
sage handling and communication. Developers just supply 
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the applicatioD-^ecific message names and their handlers. 
For C server programs use server-template. C. For C++ 
programs use server__template.cc. The templates are in the 
ICE-T installation directory under Templates/C and 
Templates/C++ respectively. 

Each server program template calls a default main routine. 
The default main ( ) routines are provided for convenience. 
If you choose to write your own main ( ) routine, look at 
default_main.c or default_main.cc for guidance and follow 
the steps in "Modifying t3he Default main Routine 
(Optional)". 

FIG. 28 is a table which describes the functions devel- 
opers must fill in using the server program template. All 
three return integer values of 1 (TRUE) or 0 (FALSE). A 
return value of 1 (TRUE) indicates that the application 
startup can proceed. A return value of 0 (FALSE) indicates 
a problem that results in stoppii^ the application. The 
remaining functions in the server program templates can be 
used as provided. 

FIG. 29 is a table which illustrates Server Properties in 
accordance with a prefened embodimenL 

Handling Messages in the Server Program 



In developing a Presentation Engine, a key task is writing 
the code that handles messages. The same task is performed 
for the server program. It consists of similar steps: 

Write the cocfe that handles incoming events (typically 30 
requests for data) 

Register the event handlers 

To handle messages in the seiver program: 

1. Write a function to handle each incoming message. 
Each function you write takes one argument, a SrvMessage( 
) function, and has a void return type. 

The function should extract the data from the message, 
and then call application logic to process it or send a 
message back to the client. 

For example, here is a handler function in C that responds ^ 
to a message with the data: employee name (empName) and 
employee number (empKumber): 
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-continued 



* Now process the data... 
-/ 

lookupEmployee (name, number); 



2. Resister the message handlers. 

Fill in the createMessageHandler ( ) function in the 
server-template to register the handlers with the server 
Communication Library. 

Note that you just use the oode in the example as is. You 
don't need to specify anything other than the names of the 
messages and the functions that handle them. For each 
handler you register, add a SrvComm_addMessageHandler 
( ) call. The arguments to the functions in this example arc 
the application-specific names of the messages and handlers 
you defined in Step 1. - - - - - 



int creatcMessageHandlers ( ) { 

SrvComm_8ddMe8sageHBndler ("Double'*, handleDouble); 

SrvComm^ddMessageHandler 

CiirstNameEntered", handleSearchMessage^ 

/A.. 

tetam 1; 
} 



void haQdleEi]:q)loyeeRecord (SrvMessagp ^message) { 
SivData *empName; 
SrvData *empNumbei; 
char *oame;. 

int num; 

r 

* disassemble icoomiiig data 
•/ 

empName- SrvMessage_getDataElement (message, 0 ); 
empNumber-SrvMessage_getOataElemeiit (message, 1 ); 
name>SivStrizig_^t\^ae (empName); 
num -SrvInteger_getV%Iue(empNumber); 

r 

* Now process the data... 
•/ 

kxikupEmployee (name, muriber); 

Here is the handler function in 

void handleEn^oyeeReoord (SrvMessage ^message) { 

r 

* disassemble incoming data 
•/ 

SivData "enqiName- mcssagc-^gctDataElemeot 
SrvData *'empNumben>message >getDataElement (1); 
char *name-empName >get^^ue ( ^ 
int num ■»empNnmber->gctWuc( ); 

r 



Modifying the Default Main Routine (Optional) 

Once the server component of the application includes 
definitions for how it handles messages and registers those 
handlers, it can call the server Communication Library. 
Those calls are defined in the default main routines provided 
35 by ICE-T: default__main. c and default _maio. cc. 

default_main. c and defaulLjnain, cc are in the ICE-T 
installation directory under Server/Main. 

This section describes the order and usage of the calls to 
the server Communication Library. 

If you create your own main or modify the default, follow 
the instructions in this section for including the calls that 
enable the server program to work with the ICE-T Commu- 
nication Layer. 

To connect the server program to the (jommunication 
Library: 

1. Include the ICE-T header files. 
The default_^ain files inchide the header files already: 
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#indude 
#indude 
#iodi»le 



"SrvData.h" 

"SrvOomm.h'* 

"SrvMcssagcb** 
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2. Call create_SrvComm ("tcp") to create the Commu- 
nication Library's data structures. 

char *protocol="tcp"; 
create_SrvComm(protocol); 

3. Call setSrvCommProperties ( ). (Optional) Set server 
properties. The setSrvCTommproperties ( ) fimction is typi- 
cally implemented in a separate file that is linked to the 
server program as part of die build process. 

4. Call createMessageHandlers ( ). 

See "Handling Messages in the Server Program" for 
information about how to use createMessageHandlers 

(). 
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5. Call SrvComm_crealeSocket () to create the listener 
socket and output the port number. 

f^QlQ — Do not write anything to stdout before you make 
the SrvCoiDnu-createSocket ( ) call. 

6. Initialize the application. 

7. Call SrvComm__aoceptClientC6nnection ( ) to a ccept 
the connection Erom the client. 

Note that the order of Step 7 and Step 8 may be inter- 



8. Finally, call SrvComm-start () to start the Communi- 
cation Library's loops. 
This routine docs not return until everything is finished. 

Building ICE-T implications 

Building an ICE-T application consists of modifying a 
make file for the client and server programs, and then using 
it to make both programs. 

ICE-T provides a makefile (Example.mk) for both the 
Presentation Engine and the server programs. Example.mk 
is in the ICE-T installation directory tmder Templates/C or 
Templates/C-H-. These files are copied to the/implications 
directory. 

To use the makefile, modify it to specify the: 
Compiler location 
Libraries location 

ICE-T installation directory (optional) 

Qient and server source file locations and names 

1. Open Example.mk in an editor and follow the instruc- 
tions in the file. 

2. Supply the locations of the conopiler, libraries. If you 
have moved the ICE-T installation directory, supply its new 
location. There is do need to change the location of the 
ICE-T installation directory. If you choose to move it, supply 
the name of the location in the TCET-INSTALLrDIR macro. 

The macros for which you provide values are shown 
below as indicated in the code: 



### Environment Configundon ### 



# Change the fdlowing lines to indicate the location oC youi compiler. 
# 

COMPILEIL-BIN- 
COMPILER_LIB- 
# 

# Cbangie the following line to indicate the location of the tCET 
installation 

# directory (either absolute or relative to the current dixedoxy). 

# The default value (.7..) aUows you to build an example in-situ in the 

# installation hierarchy. 
# 

ICET - INCTAIi. - DIR-../.. 



3. Change the macros for the Presentation Engine source 
files. This example specifies the Java files for the Presenta- 
tion Engine template (pe_template.java) and a user inter- 
face file named myGui.java. The macros for which you 
provide values are shown here in bokl type. Change the 
names of the files to those used in your application: 
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-continued 
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f (Configurable Macros)### 



# Change the following macro to add your java files 
# 

PE_SOURCE5. java- \ 
myGui.java \ 
pc_template.java \ 
#end 

# 

# Change the following macro to indicate which of the java classes 

# is the top level class (Le. the subclass of presentationEngineX 

# Note: specify this class without any extension, e.g: 

# PE_MAIN__CLASS=myPrcscntationEngine 
# 

PE_MAIN_CLASS«»pc_tcmplat6 



Examplie.mk specifies files" for the server program tiem- 
plate (server_template). The macros for which you provide 
20 values are shown here in bold type. There is a macro for C 
source files and one for C+-I- source files. Change the names 
of the files to those used by the server program in your 
application: 
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Server ### 

(Configurable Macros) 
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# change the following macro to add xc (C Plus Plus) files 
# 

SERVER_SOURCES.co.\ 
#end 

# 

# change the following macro to add .c (C) files 
# 

SERVEIL.SOURCES.o\ 
default__main.c \ 
server_Jten:9late. c \ 
#end 

# 

# change the following macro to indicate the name of the 

# server executable 
SERVER - Serverlbmplate 



Build the client program with the following command: 

% make -f Example .mk pe 

Build the server program: 

% make -f Example .mk server 

Both pe and server are defined for you in the Makefile. 
Testing ICE-T Applications 

You can test the Presentation Engine alone or with the 
server program. You have to build the programs before you 
test them. 

Run the Presentation Engine class by itself using the java 
command. 
For example: 

% java myPresentationEngine 

To test the Presentation Engine with the server program: 
1. After you have made the server program, run it to get 
the port id. 

This example shows the result of running a server pro- 
gram named myServcr: 
% myServer 

//ICE LOG messages deleted from this example. 
37526 129,146.79.147 
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ICE: rApplicatiooServer: port-37526 ServerlP*- applicatioos available and includiDg links to an HTML 

129.146.79,147 file for each application. Use splashTemplate^hlml. 

2. Supply the server machine IP and the port id as "Creating a Top-Level HTML File" describes this step, 
aigu^nts to the java co™d. For example, using the ^^^^^^ ^^^^ appUcation. Use appTem- 
machine and port id from Step 1: 5 ^^^^^ 

% Java myPr«entationEngine 129.146 J9.147 37526 .J^^^ ^^^^ Applfcation WTML FUes" describes 

3. To test the Presentation Engiae m debug mode, use the * 
-debug option to the Java command. Th&— debug option 

should be the first argument after the class name: ^^^^ gj^^p ^j^^ 

% java myPresentationEngine— debug 129. 146.79. 147 *° 

37526 A startup applet provides a way to launch an ICE-T 

application from a Web page. The startup applet: 

Configuring and Deploying ICE-T Applications starts the HTTP access to the server 

In addition to tools for developing a Presentation Engine, is Authenticates the user 

ICE-T provides these components to support application Starts the server program 

deployment, execution, and administration: Downloads the Presentation Engine as an applet to the 

Installation scrq>ts * Web page or opens the applet in a separate user* 

The following installation scripts are in the ICE-T instal- interface window (developer's choice) 

lation directory under/bin: 20 You can use the starti^letDcvIR.java template to launch 

ice-httpd-sctup the applications you build, or create your own applet. The 

Sets up the directories you need on the server. template is completely generalized so that it can be used for 

ice-install-access ^"V applications. You supply the application name in 

Installs the Access Uyer on the server. * separate parameter to the applet tag. (See "Creating 

. ^ 25 Individual Application HTML Files".) 

^■^ch compiled Presentation Engine and server Ap^en^^B"" """^^ ^ ^""^ startAppletDevIR.java is in 

program on the server. default, the startup applet opens the Presentation 

Access Layer Engine in the same window. To have the Presentation Engine 

Acts as gatekeeper for HTTP communication between the 30 appear in a new browser window, open 

client and server nodes. The Access Layer is a cgi-bin starti^letDevlR.java and follow the instmction in the file: 

executable that identifies and authenticate users. You can 

modify the e files used by the Access Layer and then use the 

supplied makefile (Access.mk) to build a customized Access 

program for use with ICE-T server applications. 35 Appictcontext cont = app.qctAppietContext( ); 

/4)pHcation startup applet template (Java) ^ ^'^Syli^m'^ajnn^ ("Showing document: [-+ncwURi^-r'); 

A template for making Java applets that launch ICE-T contshowDocument (ocwURL); 

applications. The template is in the ICE-T installation direc- /* 

tory under StartApplet. * ^P^** another window, replace the 

~, . ^ * • * it\ * ^ line above with the cominented line below. 

Web server (user must mstall) 40 

Supports HTTP coiuiections; enables Web access and the //conLshcrwDocumcnt (ncwURL), "ncw_window"); 

use of a browser front end for executing an ICE-T ^ 

application. 

Note — Sun internal users can install the Web server from 

/home/interaet/CERN/httpd/. The directory contains a *5 Creating a Top-Level HTML File 
README file with installation instructions. 

Deploying and maintaining ICE-T applications involves ^ » top-level HTML file, or "splash page " to 

these steps: present the list of available applications with links to the 

1. Using a stamp applet and HTMLpages to launch ICE-T application-level HTML pages for them. When a user 
appUcatioiK chooses a link, the link takes them to an application-level 

2. Settii^ up the Web server KTML page. 

3. Customt2ing (optional) and installing the Access Layer ICE-T provides a default HTML file for the "splash page.*' 

4. Rimning installation scripts for Presentation Engines The file, called spllashTemplate.htmU is in the ICE-T instal- 
and server programs lation directory under StartApplet. You can use the default 

5. Configuring application management files file or make one of your own. 

TT • ^ A 1 . JTT^#T To create a top-level Web page for listing the links to your 

Usmg Startup Applets and HTML Files appUcation Web pages: 

Compiled Presentation Engines can nm as applets in a 1. Copy splashTemplate.html to another file. For example: 

Java-enabled browser. To enable users to launch ICE-T ^ 1 . r„ . . . . , * o 1 l,, » 

applications from a browser use the named ICE-T templates '° f ^splashTemplate.html myAppSplashPage.html 

*^ 2. Open the file m an editor. 

3. Provide a title for the page and any text you want to 

Oeate a startup applet for cadi apphcaUon. Use the include about the application(s) listed there. 

starlAppletDevIR. java template. 4^ supply the name and the URL of the application-level 

"Using the Startup AppW describes this step. 55 HTML page for each listed application. For example, if you 

Create a top-level HTML file with links to each applica- used appTememplate.html to create an HTML file for an 

tion. This file serves as a ^splash page" identifying the application named MyApplicationl: 
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^lockquote> 
<hr> 

<imni> <applct code ="slart Apple tDevIR. class" width=400 

height=400> 

* <param Dame=AppName vaiue="My Application 1"> 
<a hief»'*MyAppiicationi±tmi"> <param nameBAcoess values'' Access"> 

MyApplicationl </applet> 

• <yhtni]> 

10 Wheo the iiscr launches the startup applet and sends the 

user data and the application name to the server, ICE-T's 
Access Layer: 

Authenticates the user name and password 

5. Copy the file to the appioptiate location on your Wfeb Downloads the Presentation Engine as an applet in a Web 
^f^f- IS page 

Tbc resiilt is a Web page with a link to the named part of the process of determining access and down- 

j^ucation: loading Presentation Engines, the Access Layer relies on an 

Myi^plication 1 . . , ^ ._ . j application configuration file to provide information about 

When a user dtioc^ this liidc^ the browser lo«b an [^^^j^^ ^^^^ components. ICE-T's 

apphcatioo-levelHTMLpagp with the startup applet for the 20 ^ay^^ installation script generates the application 

VP^^ ^ configuration file automatically. That configuration is the 

Creating Individual Apphcation HTML Files generating an lUML wrapper file in which to 

download the I^esentation Engme. You can accept the 

Think of the application-level HTML file as the Presen- defaults and let your application tise the generated HTML 

tation Engine startup page. This page contains the startup ^ wrapper, or you can customize the application configuration 

applet that results in tfie Presentation Engine being down- file so that it generates a customized HTML file to hold the 

loaded. Presentation Engine. See "Configuring implications" for 

When the user launches the stamp applet, the startup more information, 

applet takes the name of the application from the applet ^ ^ . . w k c 

parameter, the user name, and the password and sends these betting up the Web Server 

using H'lTF to the Access Layer on the server. Note — Complete the following Web server setup before 

To create an application-level Web page: mstalling the ICE-T application, that is, before running 

L Copy alDIDTemlDlate.html to another file. For ice-app-install. 

example: 35 ^^^P establishes a Web server file structure for the 

% cp appTemplate.html myAppPage.html ^^^^ acce^ to and delivery of cUent 

2. Open the file in an editor. apphcaUons. To estabhsh this file structure, run the script 

3. Include instructions to the user on how to launch the Provided in the ICE-T installation directory under /binAoe- 
application. (Optional) startAppletDevIRjava defines a -setup. 

Send button and a class (scndBtn) that handles the user's 40 Before you run this server setup script, you should estab- 

input. appTemplate.html includes default instructions for ^ ^ the cgi-b in directory and the httpd-docs 

using Send If you want to change the user's interaction with directory. 

the stamp applet, you would need to change the sendBtn Create a symbolic link to the cgi-bin and httlDd-docs 

class and the instructions in appTemplate.html. directories using the UNIX In command. 

4. Specify the name of the startup applet. If you have 45 Become superuser 
copied startAiDiDletDevIR.java, given it another name, and Make the links: 

compiled it, supply that name to the applet tag: ^ ^ _^ <absolute path to cgi-bin>/cgi.bin 

^T^i code-«startAppletDevIR.class" width^OO ^ ^ _^ <absolute path to httpd-docs>/WWW-docs 

teicJht«400> Ifyou cannot create these links, provide the absolute path 
5 Provide the apphcaUon name as a parameter to the 50 ^^^^ httpd-docs as arguments to the ice- 
applet tag. For example: ^ . . „ httpd-setup script. If you have not created the links, you will 
<param name-AppName value-"MyApplicationl'*> need to change the Access Layer's default access properties 

6. Provide the name of the access program to use for this file to specify the cgi-bin and httpd-docs kx:atiDns, (See 
application. The default vahie is "Access." You may have "Customizing the Access Uyer"). If you have created the 
customized the default access file and given it another name. lioj^s^ icc-httpd-setup without arguments. 

If so, provide the name as a value to the Access parameter. prom the ICE-T installation directory, run ice-httpd- 

<param name-Access value-" Access"> setup.ice-httpd-setup takes these arguments: 

Be sure that the file you create from appleTemplate.html -cqi-bin —takes the location of the c~i-bin directory. 

contains the end applet tag </applel>. ^ xhe default is/cgi-bin. 

5. Here are the tags for a minimal HTIVIL file using -httpdndocs^akes the tocation of the httpd/docs direc- 
startAlppletDevIR, an application named 

"MyApplicationl", and the default access program name: ^^^^^^ is/www-docs. 

<htmt> flote — ^Run ice-htttpd-setup once for each machine that is 

<blockquote> 55 an ICE-T Web server. 

Please provide Usemame and Password and press the For example: 

''Send" button to launch the application. % cd <ICE-T installation directory> 
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Property 



Thble Default Access Properties 
Default Descriptioii 



^gi_bm_Iocalioa /cgi -bin 



log_destination logfile 



logging level 



If you have not created a 
link to c^-bin (as described 
in "Setting tip the Web 
Server^, provide a cgi -bin 
location here. 

The return value determines 
where log entries are 
written. Accqjted values: 
console, log01e. If you 
cfaooGC to write the log to a 
file, set the file location and 
nflfw. using the logftle 
property. 

Dctcnninc5 to what level 
the Access Layer logs 



15 



20 



% /bio/ice-bttpd-setup 

ice-httpd-setup establishes a Web server file structure for 
the files that manage access to and delivery of requested 
client applications. 

ice-httpd-setup performs these tasks: 

Creates an ICE directory under the -cgi-bin directory 

Creates a link to cgi-bin/ICE finom the httpd-docs direc- 
tory 

Creates an application startup directory under the ICE lO 
directory 

Creates an ICE/^pRepository directory 

ice-httpd-setup takes additional optional arguments. Run 
the setiip file with the -help quailifer to get a list of the 
arguments and their defaults: 

% cd <ICE-T installation dircctory> 

% /biq/ice-httpd-setup-help 

Customizing the Access Layer 

This step is optional. The Access Layer uses authentica- 
tion and access properties files to managp access to ICE-T 
applications. Developers can use the files profvided by ICE-T 
or modify them to specify their own access requirements or 
to create a number of access subsystems for use with 
different applications. 

The Access Layer uses: 

default^authenticatioD.oc 

default_authentication.cc contains a single default 
authentication function that checks the application 
name, user name, and password. By default, all users 
are authenticated. Modify the tile to specify how to 
authenticate users. 

default_access_4)roperties.cc 

dcfault_acccss ..properties contains several functions for 
controlling access log tile properties, as well as func- 
tions for specifying the Access directory, and password 40 
scrambling keys. 
With the exception of the cqi_bin_location property, 
(See table below) no modification is necessary for these 
tiles, but you may choose to change the defaults for authen- 
tication and access properties. The files are in the Access 4S 
subdirectory in the ICE-T installation directory. 

The table appearing below describes properties that can 
be modified in defatilt^aocess_properties.cc: 
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-continued 



Property 



T^ble t>efault Access Properties 
De&Qlt Description 



log^e 



scxambler_lflEy 



access attempts. Accepted 
value: none, all, starts, 
enois, debug. 

<cgL.bLnJocation>/ 
ICE/Access logs/ 
Access - pidlog 

Uses the scrambler key Return value is used as a 
provided by ICE-T. key to unscramble the user 
name and password sent 
when the user launches an 
ai^lication. If you change 
the scrambler key, change 
the scrambler key in the 
startup applet also. 
Seb up the calling 
enviionment for the 
server program. You can 
make calls to putenv () to 
set eoviionmeat variables 
whose values can be 
aooeaaed with gptenv ( ) 
Crom the seiver piogiam. 



sessionEnvironment 



for default_ 



To implement tt» authenticate ( ) function in default.. 
uthentication.oc: 

1. copy the file firom the ICE-T installation's Access 

directory. 

2. Follow the instructions in the file to implement the 
authenticate ( ) function. 

3. In Access.mk, replace this file name with yoiu^. 

To change the defaults in default_access._properties.cc: 

1. Cbpy the file firom the ICE-T installation's Access 
directory and give it a name that suits the application. 

2. Modify the file to supply application-specific values. 

3. Edit Access.mk to replace the defauh file names with 
the files you edited. Access.mk is in the Access directory. 
The user-modifiable section is marked. 

To substitute the new file name 
authentication.ccy change the second line: 
AUTHENTICAnONJOURCES.cc-\ 
default_autheaticatioacc \ 

To substitute the new file name for default_acoess_ 
properties.cc, change the second line: 

ACCESS_PROPERTIES_SOURCES.cc=\ 
default_access__propertiesxx: \ 

4. Run Access.mk. 

% make -f Access jnk 

5. After you configure the Access Layer, run ice-install- 
access. By default, Aocessink oeates a an executable named 
CustomAccess. If you have changed the default name of the 
access program, use the — source option to ice-install-access 
and specify the name you have given the access program. 
For example: 

% ice-install-access-source my Access 

Installing the Access Program 

The ICE-T Access Program installation script: 

Installs the Access program on the server in the cgi-bin 

directory that you specify 
Installs the startup applets in the/www-docs/ICE/siart 

directory. 

To install the Access program, run ice-instaU-access from 
the ICE-T installation directory: 
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% cd <ICE-T installation directary> If you did not create a symbolic link to the cgi-bin 

%/bin^cc-install-access directory as described in "Setting up the Web Server", 

ice-install-access takes four optional arguments: specify the cgi-bin location in the Example.mk file (use the 

-cgi-bin <cgi-bin location> CGLBlN_JjOCAnON macro and then mn make on the 

Ttedefau/t is/cgi-bin. ' alDiD-inslall target: 

-source <Access executable name> % make -f Example.ink app-instell 

He name of the Access program that you are copying Configuring Applications 

from. The default is Access. -rr 

-dest <Acccss executable name> lo ^^^'^ application installation script (ice-app-instaU) 

The name of the Access program that you arc copying to. generates a default application configuration file 

The default is Access. Change the destination if you want to (appConfigFile). When a user starts an application by 

use different access programs for different applications. launching a startup applet, the Access Layer uses the j^pli- 



-help 



cation Manager to look up values for server and client 



Displays the aiguments and their defaults. 15 ^'^f''^ ^e^^^^^"^ ^ appConfigFile, Using the 

connguratLon nle, the ^pucation Manager generates an 
Installing the ICE-T Application wrapper for presenting Presentation Engines as 

- - . • applets in a Web browser execution environment. (See 

ICE-T provides a script for installing applications, ice- "Using Startup i^plets and HTML Files** for more infor- 

app-install performs these tasks: ^ mation about how to use startup applets for ICE-T 
Installs the client and server executable files for the applications.) 

application To complete the last step in deploying ao application to a 

Q-eates an apphcation directory Web Browser you use one of two ways to supply 

Installs the server m>raries application-specific values in the HTML wrapper: 

Installs the Java packages used by the Java Presentation ^ ice-app-iosUU with the required arguments as 

Engine class described in "Installing the ICE-T Applicatioa'* and let 

Creates ao application configuration file (appConfigFile), create the default aiDiDConfigPilc. 

or installs a specified one ^^^^^ y^^^ application configuration file by 

„ 1 J L c T-i * I.- u u modifying the automatically generated appConfigFile. 

If you akeady have an appConfigFile to which you have n j * n • • * « . .t. »• fi • 

, Tj . . ,. ^ By default, ice-app-inslall creates the apphcation file in 

made changes, you can avoid havmg the application ^. f ... a n •* j- j 

installation o;rerwrite it. Use the -appConfigFile /cgi-bm/ICE/ICEAppRepositoty directory and names it 

. rr o <appName>.appconf. 

^ * To customize the appConfigFile generated by icc-app- 

Copies the alDlDConf igFile to the application directory install: 

Installing the ICE-TApplication with ice-app-inslall 35 1. Open the generated configuration file 
Not&— Run ioe-app-instaU for each application you want (<appName>.appconf) in an editor. 

to install. 2. Supply the names for each application in the appropri- 

From the ICE-T installation directory, run ice-app-instaU ^te lags in each appConfigFile. You are required to supply 

with the required arguments: appUcation information in these tagis: 

-appName— the name of the application 40 <peaass>— the name of the Presentation Engine class 
-peQass^the name of the Presentation Engine class <serverName>— the name of the server program 
-pcSource— the location of the Presentation Engine you <PresentationEngine^-specifies where the Presentation 

want to mstall Engine appears on the Web page. 

-serverName — the name of the server program ^5 The ^implication Manager replaces the <Presentation 
-serveiSourc© — the k)cation of the server program you Engine> tag with a Java <applet> tag that specifies the 

want to install named Presentation Engine (peClass). 

If peSouroe and serverSource are the same directory, you 3- Supply messages to return to the browser if user 

only need to ^cify one of them. authentication or application stanip fails. The template con- 

ice-app-install takes additional optional arguments: ice- 50 ^or authentication failure and application startup 

app-install is in the /bin directory of the ICE-T application failure messages. 

installation directory. You can run the file with the -help The appConfigFile contains optional tags for you to 
option to get a list of the aiguments and their defaults: specify a Web page title, headings, and text, just as you 

% cd <ICE-T installation directory> ^^^^ ^^r any Web page. 

%/binAcesipp-install-help « The Application Manager also uses a pro^^^^^ 
, F what applications are returned to the client By defatilt, the 

InstalKng Ihe ICE-T AppHcation with the Provided Application Manager retoms the application name passed to 

Makefile ^ Access Layer. You can specify another application 

to return by modifying default_appmgr_properties. 

An alternative to running icc-app-install, is to use the 50 cc.defauIt__appmg;r_propcrties.cc is described in **Custom- 
Exampte.mk Makefile to install the completed application. izing the Access Layer". 
ExamiDle.mk has defined a taigpt for installing the appli- 
cation on your Web server. If you have set up the Web server. Presentation Engine Template 
creating the symbolic links as described in "Setting up the ICE-T provides a null application that you can use as a 

Web Server" then you can use ExamiDle.mk with the 55 template for Presentation Engines. You can find the file for 
following argument: the template in the ICE-T application installation directory 

% make -f Example jnk app-install under /Tcmplates/pe^template.java. 
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Code Example A-1 pe_template.java Listing 

import suii80&ice.pe."; 

import java.iiet*; 

import java.io.*; 

import java.applet*; 

import javB.util.*; 

import javaAwt*; 

r 

* This is a sample template of the ICE-T Presentation Engine - it needs to 

* be filled with the actual w\ names of message and handlers to create 

* a woddng PE. 
•/ 

// Extend the PrcscntationEngine class 

public dass pe^template ftxtcnds Ptesei^tionEngine { 

// CoDstmctor 

public pe_tenq>late( ) { 

// This is required. It sets tip the internal PE cx>nq>onentB 

super( ); 

} 

Code Example A-1 pe_templatejava listing (Continued) 

r* 

* This is called when the cunect applet terminates. 

* It needs to be customized for handling the termination 

* of the cnnent i^let 
•/ 

public void terminate (String reason) { 
super. PEterminate(reasoaX 

r* 

* This can be used to do any local initializations that may be required in 

* the PE. tt is called before all the connections are setup with the server 

* so no messages shotild be sent from this function. 
V 

protected void initialiae^plication( ) { } 
/** 

* createUl creates the UI components of the applet 

* It uses the "uT* object of "guf* class vdikli is generated 

* by the SpecJava gui builfter. 
V 

* Specify the UI of the application in diis function. 
V 

protected void createUI( ) { 
// create local awt conqponents to vea^ tlw ones generated 
// by SpecJava. For exan^le: 

} 

r 

* createModel Creates the data items in the Model. Some data items 

* can be observable. These items which have an associated observer 

* fimction that gets called when the observable is i^dated. 
V 

11 This function is optional. It is only needed if the 

// application wants to do some dient>side plication logic 

// Unoomment the lines below if you plan to do client side processing 

// in the Model. 

Code Example A-1 pe_template.java listing (Continued) 
protected void createModeI( ) { 

//create the observable objed e.g. PeHashtable^ FeVector, PeStiing . . . ) 
//Attach observer to the observable, 
//put the obseivables into Model 
} 

* provide the mapping of Message names to handlers foi the inbonnd 
" Messages to the PE from the UI or Comm adaptors. 

* The Handlers for the UI and Model messages should 

* be provided in this function. 
V 

// This function is required. It keqM the mining of UE events 
// registered with the uiAdaptor and the model events registered 
// with the model 

protected void createMe88ageEIandler8( ) throws 
DuplicateHandlerGxception { 
// UI maps 

uiAdaptor.addHandler ('^san^le^ui.jnessage**, 
new SampleUIHandler (niAd^tor, uiContainer)); 

//. . . 

// Model Maps 

modcljiddHandlcr ("sample modcl_mcssage^, 
new SampleModelHandleKmodel)); 



//. . . 
} 

/• 

" main is used when running as a standalone Java application, 
' (Le. not in a browser environment), and is intended to do 
* ail the things that the browser would do for the applet 
Code Exan^le A-1 pe_template.java Listing (Continued) 
• 

V 

public static void main(Striiig aigs[ D { 

pe_template pe - new pe_tenq>late( ); 

pe.is^plet a felse; 

pe. getCommandLineAi^ C^iS^)* 

pe.init( ); pe. start ( ); 

} 

//////;///////////////// UI Message Handlers 
///////////////////////////////// 

class SampleUIHandler extends PeUn&ndler { 

public SampleUIHandler( PeUIAdaptor adapter, PeUI uiContainer) { 

super (adaptor, uiContainer); 

} 

public boolean execute (Object caller, PeMessagp messagie) { 

// decode the record send by the server 

// update the ui 

return fame; 

} 

} 

//////////////////////// Model Message Handlers 

///////////////////////////////// 

class SampIeModelHandler extends PeModelHandlcr { 
public SampIeModelHandler ( PeModel model ) { 
super (model); 
} 

public boolean execute (Object caller, PeMessage message) { 

Code ExampleA-1 pe_jemplate.java Listing (Continued) 

// decode the record send by the server 

//update the model - 

return true; 

} 

} 

mmililUlimniHUUn Model Obseiveis 

immimmmimmimi 

class SampIeObseiva extends FeCMxterver { 
public SampleObserver ( PeModel model) { 
super (model); 
) 

public void iqidate (Observable o. Object arg) { 

} 

} 



Startup Applet Template 



startAfalaletDevIR. Java is a Java applet that launches 
ICE-T applications. The file is generalized to run any ICE-T 
application. You don't need to change it unless you want to 
change the user's interaction with the applet. The applet 
currently asks for usemame and password and provides a 
Send button to launch (start up) the application. The file is 
in the ICE-T installation directory under/Start/^let. For 
instructions on bow to use this file, see "Using Startup 
i^plets and HTML Files". 
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Code Example B-l staitAppletDevIR.java Listing 

r* 

* This is a sample applet that can be used for gathering specific 

* user information before displaying the ECE-T application, b can 

* be customized as needed. It is loaded into the browser using the 

* index Jitml file provided 
V 

import java.net*; 

import java.io. *; 

import java.applet *; 

import java.uti]. *; 

import java.awt *; 

import sunsofL ice.uL *; 

public class staiti^letOevIR extends /^jplet { 

Code ExampleB-1 start^pletDevIItjava listing (Continued) 

public startAppletDcvIR ( ) { 

} 

public void init () { 

setLayout (new OilumnLayout ( )); 

Panel fnamep = new Panel ( ); 

fnamep.setLayout (new FIowLayout (FlowLayouL LEFI)); 

fDamep.add (new Label ("Uscmamc:")); 

l^xtField fnamclfext*- new IbxtFleld (" ••,20>, 

fnamep4uld(fname'IVxt); 

add(fnamep); 

Panel passwdp = new Panel ( ); 

passwdp. setLayout (new RowLayout (FIowLayouLLEFI)}; 

paaswdp.add (new Label(*Pa3sword: ")); 

T^xtField passwdlfcxtpi new TtottReWC' "^); 

passwdT)Ext.setEchoCharacter(*/); 

paaswdp.add (passwdTbxt); 

add(pas8wdp); 

Panel btnp = new Panel ( ); 

btnp.setLayout (new FIowLayout ( )); 

AButton cbtn = new Abutton ("Send"); 

cbULsetAction (new sendBtn ( )); 

cbtn.addCiieatE)ata ("applet",thiB); 

cbtaaddClieatData (^^usemame'^faamelbxt); 

cbtaadddientData (**passwoid",pas8vnnbct); 

btnp.add (cbtn^ 

add(btnp); 

show ( ); 

public String gctAppNamc( ) { 
appname » getParameter ("i^jpName**^ 
return appname; 

public String getAccessName () { 

String acc • getParameter (^Access"); 

Code ExampleB-1 staitAppletDevIRjava Listing (Continued) 

if (aoc — null 11 aocjequalsC* *0 ) aco^Aooess**; 

return acc; 

} 

public String getAppHost () { 
System.erx.println ("Applet: "-Ks^fdet); 
if OsApplet) { 

URL docBsuse^getDoomientBase ( ); 

System.ert.printlnCDocument base: "-HlocBase); 

apphost-docBase.getHost ( ); 

if (apphost=null) apphost-" "i 

int port«docBase.getPoit ( ); 

if (port !- -1) apphost - apphost + **f*+port; 

System. emprintlnCSeiver is: {•'+appho8t+"}"); 

}else{ 

apphost-** 

} 

return apphost; 

) 

public static void main (String agrs[ ]) { 

Frame f » new Frame ("ICE-T startup applet"); 

startAppletDevlR lap - new startAppletDevIR ( ); 

tap.isApplet«&lse; 

tap.init ( ); f.add ("Center'*, lap); 

f.resize (500,400); 

f .show ( ); 

tap.start ( ); 

} 

public boolean isApplct»tme; 

private String appname «■ new StringC "); 
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-contiaiied 

private String apphost new StringC 
} 

/* 

* scndBtn handles the "Send" button activation. The execute 

* member of this class is called when the ''Send'* button is 

* pressed. It collects all the relevant user information and 
Code EzampleB-l start^^pletDcvIRjava Listing (Continued) 

* sends it to the Server via HTTP. This is done by executing 

* the Access function in the server's cgi-bin. 

* [Note: the uscmamc and password b scrambled so it will not 

be displayed in the URL Aeld of the browser.] 

*/ 

class sendBtn extends Activity { 

public boolean execute (Object caller. Event event) { 

AButton btn- (AButton) callei; 

startAppletDevlR app « (starlAppletDevIR) (btn.getClientData Capplet")); 

TextField name • (lixtField) (btn.getClientData 

(**usemame*'3); 

TextField passwd - O^xtField) (btn.getClientI>&ta 
(♦•password")); 

String servemame - app.getAppHost ( ); 

URL newURL - null; 

String useraame=name.gBfTbxt ( ); 

String useipasswdopasswd.getlbxt ( ); 

String appname •> app.getAppNamc ( ); 

String accessNameaapp. getAcoessName ( ); 

AccessSciambler scrambler«new AccessScrambler ( ); 

System.en.priatln ("Scrambling ("•Hisemame-t-'*, 

//userpasswd+", "+ 

appname+'^"^ 

String scrambled-scmmbler^CfambleUser (usemame, useipasswd, appname); 
System.en.printhiC scrambled — > ["«crambled*''I')5 
String uri ""htxp-Jr + servemame + 
"/cgi-bin/'+accessName + + appname + 

+ scrambled; 
System.eaprintln (uri); 
try{ 

newURL = new URL(url); 
} 

catch (Exception e) { 

Systemxn.println ("Exception Getting newURL firom ("•furiO* '*'*^)* 
} 

.^ptetContext ooot — app. getAppletContext( ); 
if (coot !- nail) { 

Code ExampleB-l staitAppletDevIKjava Listing (Continued) 

r 

* Tlw call to ShowDocumcnt makes the httpd request to the Access 

* cgi-bin executable. 
* 

* Call showDocument with one argument (the URL) to show the 

* PE in a sin^e window; call with two argomeats (the URL ''ttew__wtndow^ 

* to show the PE in a new browser window. 
• 

* We're currently defaulting the call to bring up a new browser 

* window because of the way browsers handle backing out of html 

* pages with java applets - - if you go too far back, then the applet 

* is destroyed. We pat the PE in a new window to minimize the chance 
" of going too &r back simply because you want your browser back, 

* but don't intend to kOl your PE. 

V 

System, eir.println ("Smwing document in new window: ["-f newURLV] in 
window: C+*Ppname^-")**X 
conLshowDocument (newURL, appsamt); 
//conLshowDocumenI (newURL); 

//Systemxrr.println ("Showing document: [**-fnewURL4-**f *); 

return true; 

} 

} 



Server Program Templates 

This appendix contains code listings for the following 
templates: 

server_template .c 
dcfault_main.c 
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seiver_template.cc 
defaulL_main.cc 

Chapter 2, "Building Program Components describes the 
location and use of these templates. See ''Handling Mes- 
sages in the Server Program" and "Modifying the Default 
main Routine (Optional)" for more iaformation. 



60 



C-H- Files 

ICE-T provides a serter program template and a default 
main routine for application developers using C^-i- to 
develop server programs. 

C++ Server Program Ibmplate 



Code Example C-1 seiver_template.cc listing 

r 

* 8crver_lemplatc.cc 
« 

* This is a ten^Iate of a ICE-T server-appltcation in C-m- 
•/ 

#LncIude <stdio.h> 
^iKnclude <string.h> 
#include <sys/kypes.h> 

// these are required to get the server side ICE-T components 

#includc "SrvData-hh" 

#include **SrvComm.h" 

#include "SrvMessage.hh'* 

«define false 0 

#define true 1 

/"""" 

* The Message Handler fiunctions * 



/* This is the Message handler function that gets called when a apeciiied 

* message is received from the clienL It has only one argument 

* (msg) that contains the message name and message data. 
*/ 

void handleMessage (SrvMessag? *m8g) { 

r 

* disassemble incoming data 
*/ 

Code Example C-1 server_tempIatB.cc listing (Contintied) 

r 

SrvData "data; 

dataBmessagc->getDataElcmcct (0); 

V 

/* 

" The application "Logic" */ 
•/ 

r 

* Assentble outgoing data 
•/ 

// send a reply if necessary. <iqplyData> can be of the types 

// provided in SrvData.hh 

/* 

SrvMcssagc *rq)ly»ncw SrvMcssagc (**replyMcssagcNamc^'); 

reply->adclDataElement (<replyMes8ageData>); 

SrvCamm_seBdMcssage (reply); 

•/ 

} 

//This is an example of a shutdown handler on the server 

void shutdownHandler (SrvMessage "shutdownMsg) { 

char "^hutdownl^pC" (CSrvString *) shutdownMsg->getDatBElement (0))- 

>gct\fchie 0; 

char *reasonStrittg- ((SivStrii^ *) sbiitdownM9^->gfstDataElement (l))->gctViIue 

(); 

if (Istrcmp (8hutdownType,TCEr_CLIENT_SHirnX)Wrr)) { 
^rintf (stderr,''shutdownHandler: Detected CLIENT SHUTDOWN event 
ReasoQ=%s\n'\ rcasonString); 

} else if (!8trcmp (fihutdown1Vpe,"ICEr_CLIENT_DISCONfNECr)) { 
fprintf (stdciT,"shutdownHandlcr: Detected CLIENT DISCONNECT event. 
Reason-%s\n", rcasonString); 

} else if (!strcmp(shutdown1Vpe,*TCEr_SERVER_SHUTDOWN*0) { 
^rintf (stderr^^shutdownHandler: Detected SERVER SHUTDOWN event 
Reason»%s\a'*, rcasonString); 

} else if (Istrcmp (shutdownTVpe,-ICEr_INTERNAU_SHUnX)WN')) { 

Code Example C-1 scrver_template.cc Listing (Contintied) 

fprintf (stdeiT^'shutdownHandler: Detected [NTBRNAL SHUTDOWN event 

Reason-%3\n", reasonString); 

}else{ 

^rintf (stderr/Shutdown Handler: unknown msg type (%&). Reason-%9\n'*, 
shutdownlVpe, reasonString); 
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-continued 



} 
} 

/•• 



* Fticctions required by de&ult-mais, that set the 

* SivComm library properties (setSrvCGmmPrapeities) and 

* initialize the apfdicatfonSeivicc (InitializeApplicationSeivioe) 

m 



int sctSrvCommPropcrties ( ) { 

r The server timeout is how long the server waits between receiviog 

* messages from the PE before it initiates the tim,oi^ shutdown procedure. 
V 

SrvComni_setScrverTiineout (300); /• in seconds •/ 

f* The accept timeout is how long the server will wait to accept a connection 

* from the client before it shuts dowiL 
V 

SrVODmn;_sctAcceptTimeout (400); /• in seconds •/ 

return 1; 

} 

int createMessageHandlers ( ) { 

SrvCbmm_oddMcssagcHandlcr ("San^IelncomingMcssagc", handlcMcssage); 
SrvComm_addMessageHandler ("ICEr_SHUTDOWN", sfautdownHandler); 
return 1; // (return 0; if there is a problem here) 

int initializcApplicatioa () { 

return 1; // (return 0; if then is a problem initializing the application) 
DefatUt main for C-h- 

Code Example C-2 de£snlt_inain.cc Listing 



* d^iilt__main.cc 

m 

* This file implements the default main ( ) used 

* by an ICE-T server executable. 

* The stnicture of this main is that it calls 

* all the functions necessary to run 

* the tCE-T SrvCom library, and provides several 

* places for the application writer to include 

* f^jfrfication-spedfic code. These functions 

* are inq>!emented by the application-writer, 

* and are usually implemented in a separate file, that gets 

* Enked in as part of the build process. 
• 

* These functions all return int vahies, which are used to determine if 

* the startt^ of the application should continue or should be aborted. 

* In this way the application code has a hook for indicating when something 

* goes wrong (can't connect to database, or something), and passing this 

* information on to the application so startup doesnt continue. 

Return 1 CniUE) to indicate that everything is OK, or return 0 (FALSE) 

* to indicate a fatal problem that should result in aborting the application 
startup. 

* int setSrvComProperties ( ) 

* Fill in this function to set properties oo the SrvGomm library. 

* This function is called after the SivOom Ubiary is created, but before it accqits 

* a connection from the dienL 
« 

* int crcaleMcssagHandlers ( ) 

* Fill in this function to register the message handlers. 

* This function is called imediately after setSrvCommPropeities ( ). 

* int initialize;^>plication ( ) 

* Fill in this function to start up the application-specific code. 

* It is called a^r the connection is accq)ted &om the client, 

* and before the message reader and handler loops are started. 
« 

* Code Exan^)le C-2 defaulL^maiiucc listing (Continued) 
« 

* NOTES: 

* This main ( ) routine is provided for your convenience, 

* but you are not required to use it You are 

* free to write your own main ( ) routine, provided 

* you follow the requirements for ordering the 

* calls to the SrvComm library: 

* 1. First call create-SrvComm(**tcp'*); to create 

* the Gomm library's data stmctures. 

* 2. Set the properties on the Oomm library and 
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* register message handlers and other handlers. 

* 3. C^l SrvCbiiun_createSocket () to create the 

* listener socket and output the port number 

* (Mole: do NOT write anything to stdout before 
■ making this call). 

* 4. Initialize the application. 

* 5. Cail SrvConuii_acceptQientODnnection ( ) to 
** accept the connectio fron^e client 

* (Mote: steps 4 and 5 may be interchanged) 

* 6, Finally call SrvComm_start ( ) to start the 

* Gomm library's loops. This routine does not 

* return until everything is finished. 



#indude <stdic.h> 

#includc <5tdlib.h> 

#include <string,h> 

#include <sys/types.h> 

#indude "SrvComm.h" 

extern int setSrvCommPropeities ( ); 

extern int createMessagel^dlers ( ); 

extern int initializcApplication ( }; 

r-****" 

* Hie default Main 
* 

* ICE'T provides a deEralt ixma{ ) loutine 

* for IC^T server applications. 



7 



Code Example C-2 defaolt_main.oc Listing {Continued) 
int 

main( ^ 

intaigc, 

char**eigv, 

char**cnvp 

) 
{ 

char •protocol="tcp**; 

create_SrvODnun^rotoool); 

/* 

* Call user-defined function to set the propertks on the Oomm Libiary. 

* Then call user-defined function to create the Message handlers 

* and add them to the Comm library. 

* The BetSrvComfflPropeitie& function is where Coaun Library properties 

* are set All properties have reasonable deEaults, so none of them are 

* required to be w^L 
* 

* The createMessageHacdlers function is where the message handlers are 

* added, and other handlers (shutdown handler, default message handler, 

* etc) are r^jstoed. 
• 

* Requirements on these two functions: 

* 1. These functions may NOT write anything to stdout, since the Access 

* layei expects the iiist thing on stdout to be the port number that 

* the server will be listening for a client connection on. 

V 

if OsetSrvCommProperties ( ) ) { 

exit (0); 

} 

if OcreateMessageHandleis () ) { 

exit(0); 

} 

r 

* CicsUe the socket that the clicot will connect to. 

* This routine also is responsible for generating (and printing to 
Code Example C-2 defaalt_jnain.cc listing (Continued) 

* stdout) the port number so the Access layer can generate the 

* html code that passes the port number to the dient applet 

* (presentation engine). 

* (NGTE: Dd not write anything to stdout be£ore this routine is called. 

* Writing to stden is OK, however.) 

V 

if (SrvComm_createSockBt ( ) I- SRVCOMM_STArUS-0]C) { 

cxit(0); 
} 

fprintf (stdeiT,**ECE::ApplicatiOQServer: port«>%d 
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ScivcrIP»%s\n";SrvCoinin_-gBtPort ( ), SivCbmm_getIPAddiess ( )); 

fprintf (stdeiT,**\B\riVn\p"); 

£Qi]sh(stderr); 

r 

* call useiHlefined function to initialize the application 
• 

* Requirements on this function: 

* 1. This function initializes any data stmctures in the af^lication 
** that need to be initialized before messages incoming messages 

* from the client get haodlcd. 

* 2. This function must return. This means that if the application has 

* its own notifier loop that, say, listens to messages from a database, 

* then that notifier loop must be called in a new thread. 
V 

if (tinitializeAppUcation ()) { 
exit^); 

} 
!* 

* Accept a connection fibm the client ' 

* O^loclES until a connect attempt is made, or until the 

* acceptTimeout expires). 
V 

if (SrvCdmm acceptOientConnectlon ( ) !» SRVCOMM_STArUS_OK) { 

«dt(0); 

) 

r 

* Finally, we start up the server loops. 

* This fomction does not return until everything is finished. 
Code Example C-2 default_main. cc Listing (Continned) 
V 

SrvConioi._atart ( ); 
} 

/" 

* This function is called when the server times out 

* It returns TRUE or FALSE (int 1 or 0), TRUE indicating that the 

* timeout-shutdown should proceed^ FALSE indicating that no, don't 

* shutdown on Uiis timeout (the timeout timer gets reset). 
« 

V 

•/ #ifdeC_cplusplus 
extern *XT' { 
#endif 

int handleServeiTImeout ( ) { 
return 1; 

} 

#ifdet_q)lusplu8 
} 

#endif 



C Server Program Template, 



Code Example C-3 sover-temp late, c Listing 

/•* 

• server-template, c 
* 

•ICE-T server template. 
• 

V 

#indude <stdioJi> 
#iiiclude <8tring.h> 
#include <sysAypes.h> 
#indude "SrvData.h" 
#include **SivComm.h" 
#tnclude "SrvMessage.h" 
Adeline false 0 
#defme true 1 

rrhis is the Message handler function that geU called "f/bca a specified * 
message is received firom the client It has only one argument " (msg) that 
contains the message name and message data. 
V 

void handleMessage(SrvMe3S8ge "message) { 

r 
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Code Example 03 saver-temp late, c Listing 



'disassemble incoming data 
•/ 

r 

SrvData *data; data-SrvMessage-getDataElemeiit (message, 0); 
V 

CodeExaiiq)le C-3 server-template.c Listing (Continiied) 
* Tlie application "Logic" J 
Assemble outgoing data^ 

- • see SrvDala.h for how to create data types. - -SrvData ,repIyData; replyData- 
cieate-Siv>fector( ); 

Siv\ictor-8ddEIement(Tep!yData. cTeate-SrvStriiigC*Something")); J 
I 

Create the SrvMessage struct J 

I repiy-create-SrvMessage(''replyMess&ge"); 

SrvBife8sage-addDataElemeiit(replyData); J 

r 

'Send message J 

/*SivComm-sendMessagie(reply); J 

/*Hus is an exan^le of a shutdown handler on the server V 

void slmtdownHandlei(^Me&sagB ^shutdowoMsg) { 

SrvData ^sfautdownlVpeSStro SivMessage-getDataElemeat(shutdownMsg, 0); 

SrvData ^reasonSStr- SivMessage-getDBtaElement(8hntdownMsg, 1); char 

*ieasonString»SrvString-getWue(ieasonSStr); 

Code Example C-3 server-template, c listing (Continued) 

char *shutdown1Vpc-SrvString-get\Wue(shuUiownTypeSStr); 

if(/5trcmp(5hutdownTVpc,^CEr<:LIENT-SHUTDOWN~)) { 

fprintf(stdcrr,"shutdownHandlcr: Detected CLIENT SHUTDOWN cvenU 

Reason=%S\n'*, reasooString); 

} else if (strcmp(shutdown1>pe,-ICEr-CLIENT-DISCONNECr')) { 
fpritttfitstderr/sbutdownHandler Detected CUENT DISCONNECT event 
Reason-^feVa'*, reasonString); 

} else if ({strcmp(ahutdawnlVpe,''ICET-SERVER-SHirrDOWN*0) { 
^pnntC(stderr,*'sfautdownHandler Detected SERVER SHUTDOWN event 

Rcason«%s\n'*, reasonString); 

} else if (Btrcmp(shutdown1Vpe,"ICEriNTERNAL-SHUTDOWN")) { 
fipnntf(stden;'*shutdownHandler Detected INTERNAL SHUTDOWN event. 
Rcason°%s\n'', reasonString); 
}else{ 

{printC(stderr,"Shutdown Handler: unknown msg type (%s). ReasoitB%s\n", 

shutdownType, reasonString); 

} 

} 



* Functions required by de&ult-main, that set the 

* SrvComm library properties (set&vCommProperties) and 

* initialize the applicationService (initializeApplicationService) 



int sctSrvConimPropcrtics( ) { 

/*The server timeout is how long the server waits between receiving 

* messages from the PE before it initiates the timeout shutdown procednie. 

*/SrvComm-setSenreiTimeout(300)'yy in seconds */ 

r^Yht. accept timeout is how long the server will wait to aocq>t a connection * 

from the cli«]t before it shuts down. 

*/ SivCDami-6etAcc^'nmeout(400y* in seconds */ 

recnm 1; 

} 

int aeateMessageHandlns( ) 

{ SrvCt)mm-addMes8age[bndla("SampleIiicx)mingMe5ssage*\ haodleMessage); 
SrvODmm-addMessageHandlerClCET-SHUTDOWN", shutdownHandkr); 
return 1; 

) 

int tfn'ri«liwA ppltfi>rirwi( ) { 

return 1; 

) 
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Default maiofbr C 



Oode Example 04 deCauU-maiiLC lisUiig 



defiiult-inain.c 



10 



15 



This file implements the default maia( ) used by an ICE-T 
server executable. 

The structure of this main is that it calls 

all the required functions necessary to run 

the ICE-T SrvComm library, and provides several places 
for the application writer to include application-specific 
code. These functions are required to be implemented 
by the application-writer, and are usually implemented 
in a separate file, that gets linked in as part of the build 
process. 

These functions all return int values, which are used to 20 
determine if the startup of the application should continue or 
should be aborted. 

Id this way the application code has a hook for indicating 
whea something goes wrong (can't connect to database, or 
something), and passing this information on to the applica- 
tion so startup doesn't continue. 

Return 1 (TRUE) to indicate that everything is OK, or 
return 0 (FALSE) to indicate a fatal problem that should 
result in aborting the application startup, int 
setSrvCommProperties( ) 

Fill in this function to set properties on the SrvComm 
library. This function is called after the SrvComm library is 
created, but before it accepts a connection from the client. 

int createMessageHandler5( ) 



25 



30 



70 



Fill in this fiinclion to register the message handlers. 
This function is called immediately after 
setSrvCommProperties( ). 

int initializcApplication( ) 

Fill in this function to start up the application-specific 
code. It is called after the connection is accepted from the 
client, and before the message reader and handler loops are 
started. 

NOTES: 

This main( ) routine is provided for your convenience, 

CodeExample C-4 default-maim.c Listing (Continued) 
but you arc not required to use it. You are free to write 
your own main( ) routine, provided you follow the 
requirements for ordering the calls to the SrvComm, 
library: 

1. First call create-SrvComm("tcp'*); to create the Comm 
library's data structures. 

2. Set the properties on the Comm library and register 
message handlers and other handlers. 

3. Call SrvComm-createSocket( ) to create the listener 
socket and output the port number (Note: do NOT write 
anything to stdout before * making this call). 

4. Initialize the application. 

5. Call ScvCbmm-acceptClientConnection( ) to accept the 
connection from the client. (Note: steps 4 and 5 may be 
interchanged) 

6. Finally call SrvComm-start( ) to start the Coimn 
library's loops. This routine does not return until everything 
is finished. 



#iiiclude <stdio.h> 

#uicluds <stdllb.h> 

ilKnclude <struigJi> 

delude <8ys/types.h> 

#include "SrvComm. h" 

extern int setSrvCommProperties( ); 

extern int crealeMessageHandlers( ); 

extern int iiutializcApplicatioii( ); 



* The de£Bult Main 
• 

* [CE-T provides a default inain( ) routine 

* for [CE-T server applications. 

int 

main( 
intargCj 
char* *argv, 
cliar**envp 

) 
{ 

char jprotocol-^tcp"; 
crcatc-SrvCOmm (p rotocol); 

r 

*Cal\ user-defined function to set the properties on the Conun Library. * Then 
call user-deilned function to create the Message handlers * and add them to the 
Comm library. 

Tbe setSrvCbmmPropexties fiinction £5 where Comm library properties are set 
All properties have reasonable de&ults, so none of them are required to be set 
Tlie createMessageHandlets function is where the messa^ handlers ate added, 
and other handlers (shutdown handle^ debult message Ittittdler, etc) are 

registered. 

*Requijemeats on these two functions: 

* 1. These functions may NOT write anything to stdout, since the Access, 
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-continued 



layer expects the fist thing on stdout to be the port number that * 
the server will be listening for a client oocnection on. 

a 

*/!f (setSrvCoininPrqpetties( ) ) { 

exit(0); 

) 

if (!cicatcMessageHandlcrs( ) ) { 

«il(0); 
} 

r 

* Cieate the socket that the client will connect to. 

*This routine also is respons&le for generating (and printii^ to 
*stdout) the port number so the Access layer can generate the 
'html code that passes the port mimber to the client qiplet 
CodeExantple C-4 default-niain.c LLstmg (Continued) 

* (presezitatioQ engine). 

*(NOTE: Do not write anything to stdout before this routine is called. 

"writing to stden is OK, however.) 

V 

if (SrvConim-createSockEt( ) I- SRVCOMM-STATUS-OK) { 
exit(0); 

fprintf(stderr,*'ICE::AppUcationServer: poit»%d 
SeiverIP-%e\n'';SrvOoiiim-getPort( % SrvComm-getIPAddre88( )); 
fiprintfi(stderrAn\n\a\n"); 
fiaush(stderr>, 

* call user-defined function to initialize the application 

*RequirementB on this function: 

* 1. This function initializes any data structures in the application 

* that need to be initialized before messages incoming messages 

* from the client get bandied. 

* 2. Tliis function must return. This means that if the application has 

its own notiEer loop that, say, listens to messages &om a 
database, then that notifier loop must be called in a new thread. 

V 

if (!initklizeApplication( ) ) { 
exit(0); 

} 

A 

*Accq>t a connection from the client 

^(blocks until a ooimect attempt is made, or until the 

"aocepnimcout expires). 

*/!f (SrvComm-acceptClientCOnnection( ) SRVCOMM-STAITJS-OK) { 
emt(0); 

r 

* Finally, we start up the server loops. 

"This hinction does not return until everything is finished. 

SrvComm-start( ); 

} 

r* 

This function is called when the server times out 

It returns TRUE or FALSE (int 1 or 0). TRUE indicating that the 

timeout-shutdown should proceed, FALSE indicating that no, don't 

shutdown on this timemit (the timeout timer gpts reset). 

V 

#ifdef - -cplusplus 

extern 

#endif 

int handleServefllmeout( ) { 
return 1; 

} 

#ifdef - -cplusplus } 
#endif 



ICE-T Excqjtions Catalog D 

ICE-T client program exceptions are caught by the mod- 
ules in the Presentation Engine. The IcetExcelDtionHandler 
generates exception messages. It issues warnings and errors 
by printing messages to the Java console in a Netscape 
Navigator environment, or to the terminal where Java was 
started (in the case of the Java development kit). 

Server (Communication Library) exceptions are caught 65 
by the modules in the Commuoicatioa Layer. The server- 
BcocptiooHandler generates messages. It issues warnings 



and errors by printing messages to the application logfile if 
the application is launched firom a browser or to stdout if the 
application is run standAlone. 
Here is a sample message: 

ICET WARNING: handled in PresentationEngine.init 

Attempt to register dupUcate handlers. 

FIG. 30 is a table of client and server side exceptions in 
accordance with a preferred embodiment 

While the invention is described in terms of preferred 
embodiments in a specific system environment, those skilled 
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in the art will recognize that the invention can be practiced, 
with modification, in other and different hardware and 
software environments within the spirit and scope of the 
appended claims. 

Having thus described our invention, what we claim as 5 
new, and desire to secure by Letters Patent is: 

1. A server for a distributed system, comprising: 

(a) a plurality of client computers; 

(b) a plurality of server computers; 

(c) a network oomiecting the plurality of client computers 10 
to the plurality of server computers; 

(d) a client computer whidi executes a client computer 
application which gathers information about the client 
computer and contacts a server computer using the 
network; ^5 

(e) the server computer authenticates the information 
about the client computer and initiates a server com- 
puter code segment responsible for communicating 
with the client computer; and 

(Q the server computer transmits a client computer code 20 
segment for execution at the client computer to facili- 
tate communication between the client computer and 
the server computer. 

2. The server for a distributed system as recited in claim 

1, including a plurality of definitions that define the plurality 25 
of client computer code segments and each of the plurality 
of definitions defining bow to associate the plurality of client 
computer code segments and the plurality of server com- 
puter code segments into applications in response to a 
request by the client computer. 30 

3. The server for a distributed system as recited in claim 
1, in which the server computer code segment includes at 
least one instance of a communication library code segment 
configured to couple an associated one of the plurality of 
server computer code segments to the execution framework 3s 
code segment, and the client computer includes at least one 
instance of a comm\mication Hbrary code segment config- 
ured to couple an associated one of the plurality of client 
code segments transmitted to the client computer to the 
execution framework code segment. 40 

4. The server for a distributed system as recited in claim 
1, including a web connection which facilitates communi- 
cation from the client computer to the server computer. 

5. The server for a distributed system as recited in claim 

4, wherein the web is the Internet. 45 

6. The server for a distributed system as recited in claim 
1, including a communication protocol corresponding to the 
client code segment and the server code segment which is 
supported by a communication library on the client com- 
puter and the server computer. 50 

7. The server for a distributed system as recited in claim 
1, including a code segment which authenticates an initial 
request &om a client computer before downloading a client 
code segment and initiating secure conununication. 

8. The server for a distributed system as recited in claim S5 
1, wherein a listener socket is opened on the server, and the 
port number of the listener socket is transmitted as part of 
the code segment transmitted to the client computer. 

9. The server for a distributed system as recited in claim 

1, wherein authentication information includes a password. 60 

10. A method for enabling a distributed system, including 
a plurality of client computers coupled via a network to a 
plurality of server computers, comprising the steps of: 

(a) executing a client computer application on the chent 
computer which gathers information about the cUent 65 
computer and contacts a server computer using the 
network; 
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(b) authenticating the information about the client com- 
puter at the server computer; 

(c) initiating a server computer code segment to commu- 
nicate with the client computer; and 

(d) transmitting a client computer code segment for 
execution at the chent computer to facilitate commu- 
nication between the client computer and the server 
computer. 

11. The method as recited in claim 10, including invoking 
a plurality of definitions that define the plurality of client 
computer code segments and each of the plurality of defi- 
nitions defining how lo associate the plurality of client 
computer code segments and the plurality of server com- 
puter code seginents into applications in refuse to a 
request by the client computer. 

12. The method as recited in claim 11, in which the server 
computer code segment includes at least one instance of a 
communication library code segment configured to. couple 
an associated one of the plurality of server computer code 
segments to the execution fi-amework code segment, and the 
chent computer includes at least one instance of a commu- 
nication library code segment configured to couple an asso- 
ciated one of the plurality of client code segments transmit- 
ted to the client computer to the execution framework code 
segment. 

13. The method as recited in claim 10, including the step 
of utilizing a web connection which facilitates communica- 
tion fiom the client computer to the server computer. 

14. The method as recited in claim 13, wherein the web 
is the Internet. 

15. The method as recited in claim 10, including the step 
of using a communication protocol corresponding to the 
client code segment and the server code segment which is 
supported by a communication library on the client com- 
puter and the server computer. 

16. The method as recited in claim 10, including the step 
of authenticating an initial request from a client computer 
before downloading a client code segment and initiating 
secure communication. 

17. The method as recited in claim 10, wherein a listener 
socket is opened on the server, and the port number of the 
listener socket is transmitted as part of the code segment 
transmitted to the client computer. 

18. The method as recited in claim 10, wherein authen- 
tication information includes a password. 

19. A computer program embodied on a computer- 
readable medium for enabling a distributed computer 
system, comprising: 

(a) a client computer code segment for residence on a 
client computer and including an user interface; 

(b) a server computer code segment for residence on a 
server computer coupled to the client computer; 

(c) a code segment to enable a coimection to a network 
connecting a plurality of client computers to a plurality 
of server computers; 

(d) a code segment which executes a client computer 
application on the client computer which gathers infor- 
mation about the client computer and contacts the 
server computer using the network; 

(e) a code segment which authenticates the information 
about the client computer and initiates the sender com- 
puter code segment responsible for communicating 
with the client computer; and 

(f) a code segment which transmits the client computer 
code segment for execution at the client computer to 
facilitate communication between the client computer 
and the server computer. 
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20. The computer program embodied on a computer- 24. The computer program embodied on a computer- 
readable medium for enabling a distributed computer system readable medium for enabling a distributed computer system 
as recited in claim 19, including a plurality of definitions that as recited in claim 19, including a communication protocol 
define the phiraUiy of client computer code segments and corresponding to the client code segment and the server code 
each of the plurality of definitions defining how to associate 5 ^ ^^icb is supported by a communication library on 
the phrahty of cLent computer code segments and the ^^^^^ ^ ^ 

plurauty of server computer code segments mto apphcations / 

in response to a request by the client computer 25. The computer program embodied on a computer- 

21. The computer program embodied on a computer- readable medium for enabhng a distributed computer system 
readable medium for enabling a distributed computer system lo as recited in claim 19, including a code segment which 
as recited in claim 19, in which the server computer code authenticates an initial request from a client computer before 
segment includes at least one instance of a communication downloading a client code segment and initiating secure 
library code segment configured to couple an associated one communication. 

of the plurality of server oomptUer code segments to the tu * u a-^ 

t- 1 J * J r * * ,26. The computer program embodied on a computer- 
execution framework code segment, and the dient computer 15 J ^, r 1,. M' t , 
includes at least one instance of a communication Hbrary readable medium for enabhng a distributed computer system 
code segment configured to couple an associated one of the ^ ^^cd in claim 19, wherein a listener socket is opened on 
plurality of client code segments traiismitted to the cliwit server, *and the port number of the listener sodcet is 
computer to the execution firameworic code segment transmitted as part of the code segment transmitted to the 

22. The computer program embodied on a computer- 20 client computer. 

readable medium for enabUng a distributed computer system 27. The computer program embodied on a computer- 

as recited in claim 19 including a web comiection which readable medium for enabUog a distributed computer system 

lacilitates communication from the chent computer to the ^ * . . . - . 

server computer ^ recited m claim 19, wherem authentication mformation 

23. The computer program embodied on a computer- 25 includes a password, 
readable medium for enabling a distributed computer system 

as recited in claim 22, wherein the web is the Internet. # « * « * 
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